Re: [systemd-devel] Trying to build on a new LFS system.
2011/6/20 Marius Tolzmann tolzm...@molgen.mpg.de: Hi there.. we are also using a self-maintained LFS based gnu/linux here. we switched to systemd in Nov 2010 and it worked fine from the start.. What version are you using? And what version of kernel? Did you have to tune your kernel?? (for example devfs..) Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't enable or start a new service
On Tue, 2011-06-21 at 12:35 +0200, Lennart Poettering wrote: These units are *not* installed locally, but I want install it , how I do know what should install ? Thanks, -- Sérgio M. B. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't enable or start a new service
On Tue, 21.06.11 17:24, Sérgio Basto (ser...@serjux.com) wrote: On Tue, 2011-06-21 at 12:35 +0200, Lennart Poettering wrote: These units are *not* installed locally, but I want install it , how I do know what should install ? But why would you want that? (If you really do, you can always do something like yum install /usr/lib/systemd/system/foobar.service and yum will do the right thing, but again, that's really unnecessary.) 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] possible bug guessing mainpid when service type=forking..
hi.. On 06/20/11 21:36, Lennart Poettering wrote: This very much sounds as if the service does not wait in the top-level process that the daemon process is properly forked and finished writing the PID file. systemd tries to read the PID file immediately after the top-level process exits which means that systemd will race against the daemon there. So my guess is that ypbind-mt does something like this: fork() -- fork() -- write_pid_file() exit() exit() run_main_loop() thats it.. but it should be doing: fork() fork() -- write_pid_file() wait_for_notify()exit() notify_grandparent() exit() run_main_loop() ... the run-in-foreground patch works fine.. and as far as i understood Type=forking is just good for compatibility and daemons should not fork away anymore!? i.e. the main process should not exit before it hasn't ensure that the PID file of the daemon process has been written. Otherwise any usage of the PID file is necessarily racy. but it doesn't work without setting PIDFile= either - so the PID itself is racy, too. BTW a patch for ypbind-mt adding a -foreground commandline switch will be sent to the maintainers soon.. Nice, this is good to hear, Type=simple is definitely the ncier solution. may be it could be mentioned in the manpage where Type=forking is explained that there could be a race if the daemon is forking twice or if it behaves odd in another way.. - GuessMainPID= already states that it may not work reliable.. there was nothing written to the logs that pointed in that direction and increasing verbosity changed everything 8) tricky situation and i think systemd should not be blamed for this.. ever 8) bye marius.. -- Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de --.-- MPI f. molekulare Genetik | Ihnestrasse 63-73, D-14195 Berlin | == MarIuX GNU/Linux == Phone: +49 (0)30 8413 1709| --^-- God put me on earth to accomplish a certain number of things. Right now I am so far behind.. ..I will never die. by calvin from calvinhobbes ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying to build on a new LFS system.
On 06/21/11 08:24, Stef Bon wrote: 2011/6/20 Marius Tolzmann tolzm...@molgen.mpg.de: Hi there.. we are also using a self-maintained LFS based gnu/linux here. we switched to systemd in Nov 2010 and it worked fine from the start.. What version are you using? currently systemd v27 on production workstations and v29 on my workstation.. it works.. And what version of kernel? Did you have to tune your kernel?? (for example devfs..) kernel 2.6.35.x patched with the 676db4af linux-git commit (cgroupfs: create /sys/fs/cgroup to mount cgroupfs on) and kernel 2.6.39.x .. as far as i can tell from the build logs i activated cgroups, autofs4 and devtmpfs.. i currently don't know the exact kernel options activated to get systemd working but i think they were mentioned in this list some time ago and may be explained somewhere else ?!? - i could send you my kernel config if interested.. bye m. -- Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de --.-- MPI f. molekulare Genetik | Ihnestrasse 63-73, D-14195 Berlin | == MarIuX GNU/Linux == Phone: +49 (0)30 8413 1709| --^-- God put me on earth to accomplish a certain number of things. Right now I am so far behind.. ..I will never die. by calvin from calvinhobbes ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] possible bug guessing mainpid when service type=forking..
On Tue, 21.06.11 18:50, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: but it should be doing: fork() fork() -- write_pid_file() wait_for_notify()exit() notify_grandparent() exit() run_main_loop() ... the run-in-foreground patch works fine.. and as far as i understood Type=forking is just good for compatibility and daemons should not fork away anymore!? Yes, daemons which do not double-fork are definitely much nicer than those which do. i.e. the main process should not exit before it hasn't ensure that the PID file of the daemon process has been written. Otherwise any usage of the PID file is necessarily racy. but it doesn't work without setting PIDFile= either - so the PID itself is racy, too. Hmm? There's one important distinction here: daemons which return in the parent before having made sure that the PID file is fully written are simply broken. But services which run more than one process by default are not broken but perfectly valid. BTW a patch for ypbind-mt adding a -foreground commandline switch will be sent to the maintainers soon.. Nice, this is good to hear, Type=simple is definitely the ncier solution. may be it could be mentioned in the manpage where Type=forking is explained that there could be a race if the daemon is forking twice or if it behaves odd in another way.. - GuessMainPID= already states that it may not work reliable.. Well, GuessMainPID= does not work properly for some correctly written daemon (i.e. those which run more than one process continously). But the PID file reading will only break for broken services. We generally do not add extra comments regarding bugs in software to the documentation. We instead prefer if those bug are fixed. Which is why the comment regarding GuessMainPID='s reliability is there but no comment regarding handling of daemons incorrectly writing PID files. 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] Trying to build on a new LFS system.
On Tue, 21.06.11 20:06, Stef Bon (stef...@gmail.com) wrote: Hi, thanks for your info. I've got the following log output. Somewhere the message appears: remount-rootfs.service: cgroup is empty This is just a debug message, not really a problem. You only get this when debug logging is enabled and a cgroup runs empty. Jun 21 18:33:07 systemd[1]: Job dev-tty4.device/start timed out. Jun 21 18:33:07 systemd[1]: Job dev-tty4.device/start finished, result=timeout Jun 21 18:33:07 systemd[1]: Job getty@tty4.service/start finished, result=dependency Jun 21 18:33:07 systemd[1]: Job getty@tty4.service/start failed with result 'dependency'. Jun 21 18:33:07 systemd[1]: Job dev-tty4.device/start failed with result 'timeout'. So the gettys cannot be started since their tty devices never show up. This is most likely because your udev isn't properly set up (not run, or the systemd rules file /lib/udev/rules.d/99-systemd.rules is not properly installed). 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] [RFC] systemd syslogd
Hey William, On 06/21/2011 06:50 AM, William Douglas wrote: Lennart Poettering lenn...@poettering.net writes: In general I must say that I actually like the code (and the coding style) very much, so it's hard for me to say no to this. KUTGW, Lennart I understand your reasoning and, though I'm disappointed it doesn't look like this syslogd can make it into systemd, it will at least see some use in MeeGo. Also, thank you very much for looking through the code anyway! As this is probably the biggest hunk of C I've put together, I can use all the feedback I can get =). If you want a small logger, can't you just build busybox with only syslogd? /tmp/busybox-1.18.5$ ./busybox BusyBox v1.18.5 (2011-06-22 00:41:45 CEST) multi-call binary. Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: busybox --list[-full] or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as. Currently defined functions: klogd, logger, logread, syslogd size: 29k stripped with make allnoconfig and the above enabled. ~Maarten ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] systemd syslogd
On Tue, Jun 21, 2011 at 3:45 PM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Hey William, On 06/21/2011 06:50 AM, William Douglas wrote: Lennart Poettering lenn...@poettering.net writes: In general I must say that I actually like the code (and the coding style) very much, so it's hard for me to say no to this. KUTGW, Lennart I understand your reasoning and, though I'm disappointed it doesn't look like this syslogd can make it into systemd, it will at least see some use in MeeGo. Also, thank you very much for looking through the code anyway! As this is probably the biggest hunk of C I've put together, I can use all the feedback I can get =). If you want a small logger, can't you just build busybox with only syslogd? /tmp/busybox-1.18.5$ ./busybox BusyBox v1.18.5 (2011-06-22 00:41:45 CEST) multi-call binary. Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: busybox --list[-full] or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as. Currently defined functions: klogd, logger, logread, syslogd size: 29k stripped with make allnoconfig and the above enabled. we're not doing busybox, it's a no-no for now in MeeGo. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
