Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Wed, May 23, 2012 at 12:05 AM, Gustavo Sverzut Barbieri wrote: > On Tue, May 22, 2012 at 6:47 PM, Kay Sievers wrote: >> On Tue, May 22, 2012 at 11:13 PM, Gustavo Sverzut Barbieri >> wrote: >> >>> Lennart, Kay: I hate you damn it! :-D >> >> I have nothing against you beside that you talk total nonsense below. :) >> >>> Man, how can a fstab file be so complex to justify it? It's simpler >>> than the service files we already load. Now to simply parse /etc/fstab >>> we need to call a generator, that parses (was being done already), >>> generates a new file, that triggers inotify, that calls systemd, that >>> parses it again. Ouch, that's cumbersome at least, slow at last! >> >> Inotify? Calls systemd? Parses again? Dome already? In the above >> paragraph almost all wrong. > > Well, I did not check the code. But when the generator creates the > unit in /run, it must be notified somehow to systemd, no? Isn't it > inotify? > > Also, the generated unit must be parsed by systemd, that justifies > "parse again", or did I miss something? Generators run _before_ units are read. >>> One suggestion at IRC was to just keep systemd mount units. But if we >>> should go this route, then we should call to deprecate /etc/fstab. >>> Last time we discussed about it, people said it was not going to >>> happen since some tools were parsing and relying on it. Whats is the >>> way to go? >>> >>> The only way I thing this is sane is if we call to deprecate >>> /etc/fstab. Otherwise it's total bs :-P >>> >>> PS: please stop increasing my pid count... you know I hate it! >>> PS2: ls /usr/lib/systemd/system/systemd-* && crie out loud! >> >> I ignored the rest of it, it would not have ended good for you if I >> continued to comment. :) > > Hah, you know I'm kidding... but seriously: is there any plan to > deprecate /etc/fstab in favor of native mount units? It's not our call, we support it out-of-the-box and will do that for a long time, I guess. General purpose distros probably don't want to get rid of it, it works just fine. Self-contained systems should probably not use fstab from the start on, and are free to not ship the generator at all. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 6:47 PM, Kay Sievers wrote: > On Tue, May 22, 2012 at 11:13 PM, Gustavo Sverzut Barbieri > wrote: > >> Lennart, Kay: I hate you damn it! :-D > > I have nothing against you beside that you talk total nonsense below. :) > >> Man, how can a fstab file be so complex to justify it? It's simpler >> than the service files we already load. Now to simply parse /etc/fstab >> we need to call a generator, that parses (was being done already), >> generates a new file, that triggers inotify, that calls systemd, that >> parses it again. Ouch, that's cumbersome at least, slow at last! > > Inotify? Calls systemd? Parses again? Dome already? In the above > paragraph almost all wrong. Well, I did not check the code. But when the generator creates the unit in /run, it must be notified somehow to systemd, no? Isn't it inotify? Also, the generated unit must be parsed by systemd, that justifies "parse again", or did I miss something? >> One suggestion at IRC was to just keep systemd mount units. But if we >> should go this route, then we should call to deprecate /etc/fstab. >> Last time we discussed about it, people said it was not going to >> happen since some tools were parsing and relying on it. Whats is the >> way to go? >> >> The only way I thing this is sane is if we call to deprecate >> /etc/fstab. Otherwise it's total bs :-P >> >> PS: please stop increasing my pid count... you know I hate it! >> PS2: ls /usr/lib/systemd/system/systemd-* && crie out loud! > > I ignored the rest of it, it would not have ended good for you if I > continued to comment. :) Hah, you know I'm kidding... but seriously: is there any plan to deprecate /etc/fstab in favor of native mount units? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] OT: Races with GDM3 and accountsservice (was: Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD)
Am Dienstag, den 22.05.2012, 18:41 +0200 schrieb Michael Biebl: > 2012/5/22 Paul Menzel : > > 2. GDM 3 did not list the available users though, which had to be > > entered manually. After logging out again users are displayed fine. > > The user list is populated via accountsservice. > A D-Bus activated system service. accounts-daemon.service shows up in > your list above. So I'm wondering if there is genuine bug / race in > the way gdm interacts with accountsdaemon. It looks like a race. The next two system starts the user list was correctly populated and now it is not populated again. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 11:13 PM, Gustavo Sverzut Barbieri wrote: > Lennart, Kay: I hate you damn it! :-D I have nothing against you beside that you talk total nonsense below. :) > Man, how can a fstab file be so complex to justify it? It's simpler > than the service files we already load. Now to simply parse /etc/fstab > we need to call a generator, that parses (was being done already), > generates a new file, that triggers inotify, that calls systemd, that > parses it again. Ouch, that's cumbersome at least, slow at last! Inotify? Calls systemd? Parses again? Dome already? In the above paragraph almost all wrong. > One suggestion at IRC was to just keep systemd mount units. But if we > should go this route, then we should call to deprecate /etc/fstab. > Last time we discussed about it, people said it was not going to > happen since some tools were parsing and relying on it. Whats is the > way to go? > > The only way I thing this is sane is if we call to deprecate > /etc/fstab. Otherwise it's total bs :-P > > PS: please stop increasing my pid count... you know I hate it! > PS2: ls /usr/lib/systemd/system/systemd-* && crie out loud! I ignored the rest of it, it would not have ended good for you if I continued to comment. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 3:03 PM, Lennart Poettering wrote: > Heya, > > just a quick heads-up. I just commited to git some work that rips out > the fstab parsing from PID 1 and places this in a generator instead. The > idea is that sooner or later we only parse native unit files from PID 1, > and everything else is transformed as needed with generators. This makes > the core a bit smaller and simplifies a lot of things. > > This is quite a substantial change, and hence I am not sure I got it all > right. I am writing this mail for two reasons: to warn you that current > git might break your boot more likely then usually, and secondly: please > test this, especially if you have a more complex setup with nofail, > noauto and x-systemd.automount in the mix! Lennart, Kay: I hate you damn it! :-D Man, how can a fstab file be so complex to justify it? It's simpler than the service files we already load. Now to simply parse /etc/fstab we need to call a generator, that parses (was being done already), generates a new file, that triggers inotify, that calls systemd, that parses it again. Ouch, that's cumbersome at least, slow at last! One suggestion at IRC was to just keep systemd mount units. But if we should go this route, then we should call to deprecate /etc/fstab. Last time we discussed about it, people said it was not going to happen since some tools were parsing and relying on it. Whats is the way to go? The only way I thing this is sane is if we call to deprecate /etc/fstab. Otherwise it's total bs :-P PS: please stop increasing my pid count... you know I hate it! PS2: ls /usr/lib/systemd/system/systemd-* && crie out loud! -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
On 05/22/2012 10:16 PM, Joachim Banzhaf wrote: > Me again :) > > I use apache to serve php pages that connect to a DB2 database via the > php_pdo interface. > For this to work, I have to set a DB2 specific environment. > To make that easy, there is a shell script provided that does the > necessary adjustments (db2profile). > > With SysV init I sourced that script in /etc/sysctl/apache2 and all was > fine. > That does no longer work. I guess systemd interprets that file differently? > Are there alternatives? I mean, other than mimicking db2profile which > would need to be verifyed (and posibly adapted) after every software update. What does this script do? Depending on the details, ExecStartPre might be what you're looking for. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
On 05/22/2012 10:46 PM, Joachim Banzhaf wrote: > It sets and modifies environment variables. I'll have a look and try, See also Environment= and EnvironmentFile= in systemd.exec(5). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
It sets and modifies environment variables. I'll have a look and try, thanks. sorry for smartphone brevity ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Am 22.05.2012 22:13, schrieb Tomasz Torcz: > On Tue, May 22, 2012 at 10:06:04PM +0200, Joachim Banzhaf wrote: >> Thanks for your answers, all three of them! >> >> Am 22.05.2012 21:42, schrieb Tomasz Torcz: >>> Restart=always >> AFAIK SysV init restarts the service on failures immediatelly for some >> times, then uses a delay of some minutes before it retries, which seems >> sensible. If I understand systemd.service man correctly this is not >> possible? > > You are looking for StartLimitInterval=, StartLimitBurst= in that manpage. > Not in my version. Maybe openSUSE is a bit behind (v37) - you guys move fast! Anyways, if systemd gives up eventually by default, like Harald said, that is good enough for me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to set complex environment for apache?
Me again :) I use apache to serve php pages that connect to a DB2 database via the php_pdo interface. For this to work, I have to set a DB2 specific environment. To make that easy, there is a shell script provided that does the necessary adjustments (db2profile). With SysV init I sourced that script in /etc/sysctl/apache2 and all was fine. That does no longer work. I guess systemd interprets that file differently? Are there alternatives? I mean, other than mimicking db2profile which would need to be verifyed (and posibly adapted) after every software update. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 10:06:04PM +0200, Joachim Banzhaf wrote: > Thanks for your answers, all three of them! > > Am 22.05.2012 21:42, schrieb Tomasz Torcz: > > Restart=always > AFAIK SysV init restarts the service on failures immediatelly for some > times, then uses a delay of some minutes before it retries, which seems > sensible. If I understand systemd.service man correctly this is not > possible? You are looking for StartLimitInterval=, StartLimitBurst= in that manpage. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Am 22.05.2012 22:06, schrieb Joachim Banzhaf: > Thanks for your answers, all three of them! > > Am 22.05.2012 21:42, schrieb Tomasz Torcz: >> Restart=always > AFAIK SysV init restarts the service on failures immediatelly for some times, > then uses a delay of some minutes > before it retries, which seems sensible. If I understand systemd.service man > correctly this is not possible? Restart=always RestartSec=1 this way it doe snot flood your system and prevents race conditions, after too much retries systemd will stop restarting (no value at my hands) i use this for ALL relevant services (mail, http, mysql, samba, asterisk) since months on every production server with no single problem signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Thanks for your answers, all three of them! Am 22.05.2012 21:42, schrieb Tomasz Torcz: > Restart=always AFAIK SysV init restarts the service on failures immediatelly for some times, then uses a delay of some minutes before it retries, which seems sensible. If I understand systemd.service man correctly this is not possible? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 09:27:34PM +0200, Joachim Banzhaf wrote: > As it happens I also like IBM DB2 a lot (for other reasons). > DB2 is closed source (I hope you dont stop reading now) and it installs > an inittab entry. > > fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor > Coordinator > > You know that this does no longer work. > > Inittab is a very old, very widely spread concept so I have hope you > even have thought about porting something like this in a generic way > already and I just failed to find it? inittab is not used on general Linux for few years already. Most distros switched to upstart some time ago, upstart isn't parsing inittab (except for default runlevel). The line you provided translates to following systemd unit: /etc/systemd/system/fmc.service --- [Unit] Description=DB2 Fault Monitor Coordinator [Service] ExecStart=/opt/ibm/db2/V10.1/bin/db2fmcd Restart=always [Install] WantedBy=multi-user.target --- It simple, but let me describe it: "fmc" becomes service name - fmc.service "2345" is not directly mappable. There are no runlevels with systemd. multi-user.target is roughly equivalent of all system services started. If your inittab had "1" here (single user), you would want WantedBy=rescue.target in [Install] session. Please see "man systemd.special" for description of other targets. "respawn" becomes Restart=always The command itself lands in ExecStart=; because this command do not daemonize (requisite for being in inittab), you can skip Type= declaration. It will default to simple. You can put comment in Description field. You are now only "systemctl enable fmc.service" away of emulating inittab. Above unit definition is really simple but fully replaces inittab entry. However, please look at man pages of systemd.exec and systemd.service. You will find many way to augment this unit (various limits, chroot, running as specific user, group etc). -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 9:27 PM, Joachim Banzhaf wrote: > I found out about systemd because openSUSE uses it now. > I read the annoncement and the three updates of it and some more and can > say I like systemd a lot. > It just seems to be the right way to do process/service management. > > As it happens I also like IBM DB2 a lot (for other reasons). > DB2 is closed source (I hope you dont stop reading now) and it installs > an inittab entry. > > fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor > Coordinator > > You know that this does no longer work. > > I guess the details how such processes are started with SysV init > (environment, time of first start, how to respawn, ...) are common or > even standardized, and from what I read so far I think it can be easily > modeled with systemd for someone knowing SysV init and systemd a little > better than me. > I found some getty examples but I must admit I failed to understand all > the details yet. > > Inittab is a very old, very widely spread concept so I have hope you > even have thought about porting something like this in a generic way > already and I just failed to find it? > > Thought I ask before I try to reinvent the wheel in a try and error > fashion :) No there is no support for inittab. All proper services started by systemd can behave the way like inittab provided in the past. But they need systemd .service files. Should be trivial to manually write and add a service file for the above mentioned use case, there is no built-in support in systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 9:26 PM, Bardur Arantsson wrote: > On 05/22/2012 08:03 PM, Lennart Poettering wrote: >> just a quick heads-up. I just commited to git some work that rips out >> the fstab parsing from PID 1 and places this in a generator instead. The >> idea is that sooner or later we only parse native unit files from PID 1, >> and everything else is transformed as needed with generators. This makes >> the core a bit smaller and simplifies a lot of things. >> >> This is quite a substantial change, and hence I am not sure I got it all >> right. I am writing this mail for two reasons: to warn you that current >> git might break your boot more likely then usually, and secondly: please >> test this, especially if you have a more complex setup with nofail, >> noauto and x-systemd.automount in the mix! >> > > Speaking of which... does the code actually check for > > x-systemd.automount > or x-systemd-automount > > now? The doc and code were inconsistent about this. (I brought it up > here: http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/4990 > previously) http://cgit.freedesktop.org/systemd/systemd/commit/?id=92a39ae1989a7583d696afd4c89990aea802e9ea Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there a general inittab entry replacement available?
Hi, I found out about systemd because openSUSE uses it now. I read the annoncement and the three updates of it and some more and can say I like systemd a lot. It just seems to be the right way to do process/service management. As it happens I also like IBM DB2 a lot (for other reasons). DB2 is closed source (I hope you dont stop reading now) and it installs an inittab entry. fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor Coordinator You know that this does no longer work. I guess the details how such processes are started with SysV init (environment, time of first start, how to respawn, ...) are common or even standardized, and from what I read so far I think it can be easily modeled with systemd for someone knowing SysV init and systemd a little better than me. I found some getty examples but I must admit I failed to understand all the details yet. Inittab is a very old, very widely spread concept so I have hope you even have thought about porting something like this in a generic way already and I just failed to find it? Thought I ask before I try to reinvent the wheel in a try and error fashion :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On 05/22/2012 08:03 PM, Lennart Poettering wrote: > Heya, > > just a quick heads-up. I just commited to git some work that rips out > the fstab parsing from PID 1 and places this in a generator instead. The > idea is that sooner or later we only parse native unit files from PID 1, > and everything else is transformed as needed with generators. This makes > the core a bit smaller and simplifies a lot of things. > > This is quite a substantial change, and hence I am not sure I got it all > right. I am writing this mail for two reasons: to warn you that current > git might break your boot more likely then usually, and secondly: please > test this, especially if you have a more complex setup with nofail, > noauto and x-systemd.automount in the mix! > Speaking of which... does the code actually check for x-systemd.automount or x-systemd-automount now? The doc and code were inconsistent about this. (I brought it up here: http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/4990 previously) Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
Heya, just a quick heads-up. I just commited to git some work that rips out the fstab parsing from PID 1 and places this in a generator instead. The idea is that sooner or later we only parse native unit files from PID 1, and everything else is transformed as needed with generators. This makes the core a bit smaller and simplifies a lot of things. This is quite a substantial change, and hence I am not sure I got it all right. I am writing this mail for two reasons: to warn you that current git might break your boot more likely then usually, and secondly: please test this, especially if you have a more complex setup with nofail, noauto and x-systemd.automount in the mix! Thank you, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgtop: useful error messages when bootup fails
On Tue, 2012-05-22 at 13:12 +0200, Lennart Poettering wrote: > On Mon, 21.05.12 23:04, shawn (shawnland...@gmail.com) wrote: > > Heya, > > > Uggh, sorry for sending that super-buggy patch. Here is a better > > version. > > > > On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote: > > > cgtop quits on startup if all the cgroup mounts it expects are not ready. > > > Provide user with some indication of why cgtop failed. > > > >From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001 > > From: Shawn Landden > > Date: Mon, 21 May 2012 22:54:41 -0700 > > Subject: [PATCH] cgtop: useful error messages when bootup fails > > > > cgtop quits on startup if all the cgroup mounts it expects are not ready. > > Provide user with some indication of why cgtop failed. > > Hmm, this is misleading. THis has little to do with being ready, as the > cgroup VFS are mounted synchronously very early in PID 1 and it is > basically very hard to run in parallel with that. > > So this check actually would check for something different: whether the > system was booted with systemd at all, and whether the respective cgroup > controller has been enabled in the kernel at all. But for the former an > excplicit early check for sd_booted() would probably a nicer choice > (though I must say I shiver at the idea that we add this to all our > tools). And for the latter we should probably fix things so that the > tool works fine even if cpuacct, memory and blkio (or any subset of them > are not available), after all those controllers should be optional. 100% agree. > > How did you start cgtop so that you ran into this problem? On an armel system running systemd, but which doesn' have the memory (or blkid) cgroups sections, I presume because I didn't compile them in. (I'd rather not have the overhead of the memory one) I had to use strace to get any idea why it didn't work. I ran across a similar issue with nspawn before. Alot of these tools require specific kernel features, and why they fail correctly they don't really give useful error messages. > > Lennart > -- -Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD
2012/5/22 Paul Menzel : > 2. GDM 3 did not list the available users though, which had to be > entered manually. After logging out again users are displayed fine. The user list is populated via accountsservice. A D-Bus activated system service. accounts-daemon.service shows up in your list above. So I'm wondering if there is genuine bug / race in the way gdm interacts with accountsdaemon. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_systemd.so and su
Le jeudi 22 mars 2012 à 02:11 +0100, Lennart Poettering a écrit : > On Thu, 22.03.12 00:41, Lennart Poettering (lenn...@poettering.net) wrote: > > > On Sun, 18.03.12 16:08, Canek Peláez Valdés (can...@gmail.com) wrote: > > > > > Hi; I'm using systemd 43 in Gentoo, and I usally have this line at the > > > end of /etc/pam.d/system-auth: > > > > > > -sessionoptionalpam_systemd.so > > > > > > When I use su to become root, after logout the following message appears: > > > > > > ...killed. > > > > > > Not always, but most of the time. Without the line with > > > pam_systemd.so, the message never appears. > > > > > > So, two questions: > > > > > > 1. Why is my session being killed at logout time? > > > > > > 2. The pam_systemd.so is really necessary? The "...killed." message > > > appears after two or three seconds, and it's slightly annoying. > > > > Which version of systemd is this? (If it isnt 44, please upgrade first, > > then try to reproduce this) > > > > Do you have audit enabled in the kernel and are using pam_loginuid? > > > > Normally, when the pam session close hooks are called logind responds to > > this by killing the main process of the session if it still > > exists. This is probably the source of the problem here. > > I have now commited a patch to git that might fix your issue. Please > test: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=75c8e3cffd7da8eede614cf61384957af2c82a29 > > I assume this fixes your problem, but since our kernels actually have > audit enabled I am a bit too lazy trying to reproduce the issue here, so > I'd be very thankful if you could test this! Well, I'm able to reproduce this problem with a kernel with audit enabled and configured, unfortunately. Our patch seems to improve the situation a little bit, but not entirely, when running inside a previously detached screen session: - su -l calls aren't killed when exiting them - but sudo calls are being terminated before being started, after the second sudo call. You need to call one time "su -l", and the, sudo will work one time. (we are calling pam_systemd in a common-session file which is including in a lot of pam configuration, including sudo and su-l). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] switch-root: do not use close old_root_fd after rm_rf_children()
On Tue, 22.05.12 15:28, har...@redhat.com (har...@redhat.com) wrote: > From: Harald Hoyer > > rm_rf_children() has already closed the fd with closedir(). Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] switch-root: do not use close_nointr_nofail()
Am 22.05.2012 15:19, schrieb har...@redhat.com: > From: Harald Hoyer > > rm_rf_children() might have already closed the fd with closedir(). > We just don't know. revised patch sent ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] switch-root: do not use close old_root_fd after rm_rf_children()
From: Harald Hoyer rm_rf_children() has already closed the fd with closedir(). --- src/core/switch-root.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/core/switch-root.c b/src/core/switch-root.c index ed0a31e..9832a52 100644 --- a/src/core/switch-root.c +++ b/src/core/switch-root.c @@ -111,8 +111,10 @@ int switch_root(const char *new_root) { if (fstat(old_root_fd, &rb) < 0) log_warning("Failed to stat old root directory, leaving: %m"); -else +else { rm_rf_children(old_root_fd, false, false, &rb); +old_root_fd = -1; +} } r = 0; -- 1.7.10.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: rm_rf_children() add root_dev parameter
Am 22.05.2012 15:19, schrieb har...@redhat.com: > From: Harald Hoyer > > if root_dev is set, remove subdirectories only, if the device is the > same as the root_dev. This prevents to remove files across device > boundaries. > --- > src/shared/util.c | 39 ++- > src/shared/util.h |2 +- > 2 files changed, 27 insertions(+), 14 deletions(-) please ignore.. it's already in ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] switch-root: do not use close_nointr_nofail()
From: Harald Hoyer rm_rf_children() might have already closed the fd with closedir(). We just don't know. --- src/core/switch-root.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/switch-root.c b/src/core/switch-root.c index ed0a31e..1802dc1 100644 --- a/src/core/switch-root.c +++ b/src/core/switch-root.c @@ -119,7 +119,7 @@ int switch_root(const char *new_root) { fail: if (old_root_fd >= 0) -close_nointr_nofail(old_root_fd); +close_nointr(old_root_fd); return r; } -- 1.7.10.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: rm_rf_children() add root_dev parameter
From: Harald Hoyer if root_dev is set, remove subdirectories only, if the device is the same as the root_dev. This prevents to remove files across device boundaries. --- src/shared/util.c | 39 ++- src/shared/util.h |2 +- 2 files changed, 27 insertions(+), 14 deletions(-) diff --git a/src/shared/util.c b/src/shared/util.c index bfa9509..e6afc50 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -3131,7 +3131,7 @@ int get_ctty(pid_t pid, dev_t *_devnr, char **r) { return 0; } -int rm_rf_children(int fd, bool only_dirs, bool honour_sticky) { +int rm_rf_children(int fd, bool only_dirs, bool honour_sticky, struct stat *root_dev) { DIR *d; int ret = 0; @@ -3200,24 +3200,37 @@ int rm_rf_children(int fd, bool only_dirs, bool honour_sticky) { if (is_dir) { int subdir_fd; - -subdir_fd = openat(fd, de->d_name, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_NOFOLLOW|O_NOATIME); -if (subdir_fd < 0) { -if (ret == 0 && errno != ENOENT) -ret = -errno; -continue; +struct stat sb; +if (root_dev) { +if (fstatat(fd, de->d_name, &sb, AT_SYMLINK_NOFOLLOW)) { +if (ret == 0 && errno != ENOENT) +ret = -errno; +continue; +} } -r = rm_rf_children(subdir_fd, only_dirs, honour_sticky); -if (r < 0 && ret == 0) -ret = r; +/* if root_dev is set, remove subdirectories only, if device is same as dir */ +if ((root_dev == NULL) || (sb.st_dev == root_dev->st_dev)) { -if (!keep_around) -if (unlinkat(fd, de->d_name, AT_REMOVEDIR) < 0) { +subdir_fd = openat(fd, de->d_name, + O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_NOFOLLOW|O_NOATIME); +if (subdir_fd < 0) { if (ret == 0 && errno != ENOENT) ret = -errno; +continue; } +r = rm_rf_children(subdir_fd, only_dirs, honour_sticky, root_dev); +if (r < 0 && ret == 0) +ret = r; + +if (!keep_around) +if (unlinkat(fd, de->d_name, AT_REMOVEDIR) < 0) { +if (ret == 0 && errno != ENOENT) +ret = -errno; +} +} + } else if (!only_dirs && !keep_around) { if (unlinkat(fd, de->d_name, 0) < 0) { @@ -3251,7 +3264,7 @@ int rm_rf(const char *path, bool only_dirs, bool delete_root, bool honour_sticky return 0; } -r = rm_rf_children(fd, only_dirs, honour_sticky); +r = rm_rf_children(fd, only_dirs, honour_sticky, NULL); if (delete_root) { diff --git a/src/shared/util.h b/src/shared/util.h index 58db27f..698b60b 100644 --- a/src/shared/util.h +++ b/src/shared/util.h @@ -348,7 +348,7 @@ int get_ctty(pid_t, dev_t *_devnr, char **r); int chmod_and_chown(const char *path, mode_t mode, uid_t uid, gid_t gid); int fchmod_and_fchown(int fd, mode_t mode, uid_t uid, gid_t gid); -int rm_rf_children(int fd, bool only_dirs, bool honour_sticky); +int rm_rf_children(int fd, bool only_dirs, bool honour_sticky, struct stat *root_dev); int rm_rf(const char *path, bool only_dirs, bool delete_root, bool honour_sticky); int pipe_eof(int fd); -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 2012-05-22 at 13:26 +0200, Lennart Poettering wrote: > On Tue, 22.05.12 08:40, Sjoerd Simons (sjo...@luon.net) wrote: > > > > > On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: > > > > If journal_file_open() failed, due to (e.g.) -ENOSPC on open() > > > > new_file might still be NULL. > > > > > > > > On error, leave pointer to the old JournalFile (now closed), > > > > and require caller to check for error approiately. > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 > > > > Reported-by: Sjoerd Simons > > > > The bugzilla link seems wrong ? > > > > This actually remind me though, i did submit a patch for this issue to > > bugzilla (slightly different then your solution) more then a month ago. > > And a companion patch to not make the issue occur so easily, bugs filed > > here: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=48688 > > https://bugs.freedesktop.org/show_bug.cgi?id=48685 > > > > If the systemd bugzilla is just somewhat of a decoy i'm happy to repost > > the patches to the list ofcourse :) > > Nah, fdo bz is not a decoy. The reason I didnt merge this right away was > actually that I wanted to rework the code in question in a bigger way, > so that we have some logic in there that we automatically fallback to > kmsg logging when the journal for some reason doesn't work. But I never > found the time to. Aha! A note on the bug would have been great :). > Anyway, since this is a bug I have now merged your patch 48685, and we > can add the kmsg fallback logic later on. Thanks for your work! Np, thanks for merging :). > About 48688 I am not sure sure. i.e. should we really bind the keep_free > stuff to the reserved percentage of the FS? They are two different > things, or are they not? I'm not sure either as i mentioned in the bugreport. The standard 5% is a bit odd though. Although I may be a bit odd, but my / partition tends to never have a lot of free space, which means it's basically always below the 5% (Which is still more then 0.5G on a 10G system..). I picked up using the reserved precentage mostly as it's the one place i could think of where there is currently a configuration for "leave this much space free please". Furthermore it means that you get a no space error only when df shows you have 0 available space which is nice i'd think :).. It took me quite some time to figure out why journald was giving out of space errors while df was happily showing there was still quite a bit of space left. -- Sjoerd Simons ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 22.05.12 08:40, Sjoerd Simons (sjo...@luon.net) wrote: > > On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: > > > If journal_file_open() failed, due to (e.g.) -ENOSPC on open() > > > new_file might still be NULL. > > > > > > On error, leave pointer to the old JournalFile (now closed), > > > and require caller to check for error approiately. > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 > > > Reported-by: Sjoerd Simons > > The bugzilla link seems wrong ? > > This actually remind me though, i did submit a patch for this issue to > bugzilla (slightly different then your solution) more then a month ago. > And a companion patch to not make the issue occur so easily, bugs filed > here: > > https://bugs.freedesktop.org/show_bug.cgi?id=48688 > https://bugs.freedesktop.org/show_bug.cgi?id=48685 > > If the systemd bugzilla is just somewhat of a decoy i'm happy to repost > the patches to the list ofcourse :) Nah, fdo bz is not a decoy. The reason I didnt merge this right away was actually that I wanted to rework the code in question in a bigger way, so that we have some logic in there that we automatically fallback to kmsg logging when the journal for some reason doesn't work. But I never found the time to. Anyway, since this is a bug I have now merged your patch 48685, and we can add the kmsg fallback logic later on. Thanks for your work! About 48688 I am not sure sure. i.e. should we really bind the keep_free stuff to the reserved percentage of the FS? They are two different things, or are they not? Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: > > If journal_file_open() failed, due to (e.g.) -ENOSPC on open() > > new_file might still be NULL. > > > > On error, leave pointer to the old JournalFile (now closed), > > and require caller to check for error approiately. > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 > > Reported-by: Sjoerd Simons The bugzilla link seems wrong ? This actually remind me though, i did submit a patch for this issue to bugzilla (slightly different then your solution) more then a month ago. And a companion patch to not make the issue occur so easily, bugs filed here: https://bugs.freedesktop.org/show_bug.cgi?id=48688 https://bugs.freedesktop.org/show_bug.cgi?id=48685 If the systemd bugzilla is just somewhat of a decoy i'm happy to repost the patches to the list ofcourse :) > > src/journal/journal-file.c |9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c > > index 5dd6e57..9f5f26e 100644 > > --- a/src/journal/journal-file.c > > +++ b/src/journal/journal-file.c > > @@ -1871,9 +1871,16 @@ int journal_file_rotate(JournalFile **f) { > > old_file->header->state = STATE_ARCHIVED; > > > > r = journal_file_open(old_file->path, old_file->flags, > > old_file->mode, old_file, &new_file); > > -journal_file_close(old_file); > > + > > +if (r < 0) { > > +r = -errno; > > +goto finish; > > +} > > > > *f = new_file; > > + > > +finish: > > +journal_file_close(old_file); > > return r; > > } > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgtop: useful error messages when bootup fails
On Mon, 21.05.12 23:04, shawn (shawnland...@gmail.com) wrote: Heya, > Uggh, sorry for sending that super-buggy patch. Here is a better > version. > > On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote: > > cgtop quits on startup if all the cgroup mounts it expects are not ready. > > Provide user with some indication of why cgtop failed. > >From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001 > From: Shawn Landden > Date: Mon, 21 May 2012 22:54:41 -0700 > Subject: [PATCH] cgtop: useful error messages when bootup fails > > cgtop quits on startup if all the cgroup mounts it expects are not ready. > Provide user with some indication of why cgtop failed. Hmm, this is misleading. THis has little to do with being ready, as the cgroup VFS are mounted synchronously very early in PID 1 and it is basically very hard to run in parallel with that. So this check actually would check for something different: whether the system was booted with systemd at all, and whether the respective cgroup controller has been enabled in the kernel at all. But for the former an excplicit early check for sd_booted() would probably a nicer choice (though I must say I shiver at the idea that we add this to all our tools). And for the latter we should probably fix things so that the tool works fine even if cpuacct, memory and blkio (or any subset of them are not available), after all those controllers should be optional. How did you start cgtop so that you ran into this problem? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD
Dear systemd folks, hopefully it is alright to report my findings here. If you have any suggestions to improve the startup time, please do not hesitate to tell me. ;-) Hardware • ASRock E350M1 with dual core 1.6 GHz Fusion CPU [1] • Crucial m4 SSD connected via SATA-3-cable [2] • one Ext4 partition Software • default Debian Sid/unstable installed using `grml-debootstrap` and Grml live system • `aptitude purge mdadm lvm2` • `aptitude install systemd` (version 44-1) • `linux-image-3.2.0-2-amd64` (version 3.2.17-1) Results === 1. Passing `init=/bin/systemd` to the Linux kernel command line the GDM 3 login screen showed up noticeably faster. 2. GDM 3 did not list the available users though, which had to be entered manually. After logging out again users are displayed fine. 3. Systemd says start up took 7.5 seconds. $ systemd-analyze Startup finished in 4077ms (kernel) + 3390ms (userspace) = 7468ms 4. All units take less than a second to start. $ systemd-analyze blame 948ms avahi-daemon.service 729ms postfix.service 656ms rsyslog.service 632ms systemd-logind.service 559ms console-kit-log-system-start.service 523ms bootlogs.service 520ms chrony.service 467ms udev.service 451ms rc.local.service 436ms loadcpufreq.service 427ms keymap.service 424ms ssh.service 396ms cron.service 388ms dev-mqueue.mount 367ms systemd-modules-load.service 360ms sys-kernel-debug.mount 340ms udev-trigger.service 327ms systemd-sysctl.service 324ms dev-hugepages.mount 296ms sys-kernel-security.mount 281ms network-manager.service 279ms saned.service 279ms systemd-user-sessions.service 277ms gdm3.service 264ms media.mount 247ms systemd-remount-api-vfs.service 215ms pppd-dns.service 211ms resolvconf.service 199ms systemd-tmpfiles-setup.service 195ms screen-cleanup.service 191ms kbd.service 159ms networking.service 151ms console-setup.service 147ms pulseaudio.service 143ms cpufrequtils.service 91ms hdparm.service 91ms mountoverflowtmp.service 88ms keyboard-setup.service 87ms sysfsutils.service 87ms debian-fixup.service 59ms remount-rootfs.service 59ms colord-sane.service 56ms console-kit-daemon.service 48ms colord.service 44ms polkitd.service 31ms accounts-daemon.service 26ms upower.service 22ms udisks.service 19ms boot-efi.mount 13ms rtkit-daemon.service 5. Also I experience the sudo issue [3]. Conclusions === 1. I should follow the optimization suggestions in the systemd Wiki [4]. 2. Improving loading time of the Linux kernel should be my priority right now. With four seconds it take more than half of the total Debian startup time. I would not have expected that. I guess I need to use `bootchart` to check if the long time is due to the slow 1.6 GHz dual Fusion CPU or if the storage is not set up correctly. 3. It will be interesting if GNOME 3.4 will speed up things too as mentioned in the Wiki [4]. Currently `gnome-shell` 3.2.2.1-4+b1 is installed. Thank you very much for this promising piece of software, Paul [1] http://www.asrock.com/mb/overview.asp?Model=E350M1 [2] http://www.crucial.com/store/partspecs.aspx?imodule=CT256M4SSD2 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667470 [4] http://freedesktop.org/wiki/Software/systemd/Optimizations signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 2012-05-22 at 08:40 +0200, Sjoerd Simons wrote: > On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: > > > If journal_file_open() failed, due to (e.g.) -ENOSPC on open() > > > new_file might still be NULL. > > > > > > On error, leave pointer to the old JournalFile (now closed), > > > and require caller to check for error approiately. > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 > > > Reported-by: Sjoerd Simons > > The bugzilla link seems wrong ? yes, I was looking at your patch, (via debian BTS) but I copied the url wrong. (corrected patch attached) That is how I knew to forward it to you. I read your patch, however there are many reasons other than ENOSPC why open() could fail leaving a null pointer, and my patch takes care of that. > > This actually remind me though, i did submit a patch for this issue to > bugzilla (slightly different then your solution) more then a month ago. > And a companion patch to not make the issue occur so easily, bugs filed > here: > > https://bugs.freedesktop.org/show_bug.cgi?id=48688 > https://bugs.freedesktop.org/show_bug.cgi?id=48685 > > If the systemd bugzilla is just somewhat of a decoy i'm happy to repost > the patches to the list ofcourse :) Well the first patch I submitted to systemd bugzilla sure didn't get any traction -- -Shawn Landden >From 54a970dcf59b59ade587002925be027b71d81545 Mon Sep 17 00:00:00 2001 From: Shawn Landden Date: Mon, 21 May 2012 19:46:54 -0700 Subject: [PATCH] journal: fix dereferenced pointer in journal_file_rotate() If journal_file_open() failed, due to (e.g.) -ENOSPC on open() new_file might still be NULL. On error, leave pointer to the old JournalFile (now closed), and require caller to check for error approiately. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48685 Reported-by: Sjoerd Simons --- src/journal/journal-file.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c index 5dd6e57..9f5f26e 100644 --- a/src/journal/journal-file.c +++ b/src/journal/journal-file.c @@ -1871,9 +1871,16 @@ int journal_file_rotate(JournalFile **f) { old_file->header->state = STATE_ARCHIVED; r = journal_file_open(old_file->path, old_file->flags, old_file->mode, old_file, &new_file); -journal_file_close(old_file); + +if (r < 0) { +r = -errno; +goto finish; +} *f = new_file; + +finish: +journal_file_close(old_file); return r; } -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel