Re: [systemd-devel] systemd hang on booting after mount
On Tue, 18.01.11 14:05, Chanwoo Choi (cwcho...@gmail.com) wrote: General Setup -- [*] Control Group support -- [ ] Example debug cgoup subsystem [ ] Namespace cgroup subsystem [ ] Freezer cgroup subsystem [ ] Device controller for cgroups [ ] Cpuset support [ ] Simple CPU accouting cgroup subsystem [ ] Resource counters [*] Group CPU scheduler Block IO controller Device Drivers -- Generic Driver Options -- [*] Maintain a devtmpfs filesystem to mount at /dev [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs File systems -- Kernel automounter support * Kernel automounter version 4 support (also supports v3) But, I faced this error. How do I solve this issue? Sorry, can't help you much. very very likely you disabled some otherwise considered standard part of the kernel, so try to use a less minimal kernel and then remove options from there. Let us know if you find the option that made it. 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] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
On Tue, 18.01.11 16:41, Alexander E. Patrakov (patra...@gmail.com) wrote: How is this implemented in detail? Sending SIGINT is async, so at the time you start the new instance you cannot be sure that the old instance has stopped listening? Indeed, there is a race here. That's why /bin/sleep 1 in my initial service file. Hmm, what's the lighthttp people's take on this? They came up with the scheme, so how do they think this problem should be handled? (One possible solution could be if the old and the new instance would communicate and pass the listening sockets via some AF_UNIX socket/SCM_RIGHTS or so. But that is not trivial.) Solutions such as sleep 1 are not really how we do things in systemd land... 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] Assertion failed in systemd v16
18.01.2011 04:14, Lennart Poettering пишет: On Mon, 10.01.11 15:11, Alexander E. Patrakov (patra...@gmail.com) wrote: [Unit] Description=Lighttpd Web Server After=network.target [Service] Type=forking EnvironmentFile=/etc/conf.d/lighttpd PIDFile=/var/run/lighttpd.pid ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf Hmm, whiy is this necessary? I presumee starting the daemon will do an implicit configuration check anyway, right? I mean, how could it load the config without checking for its validity? Indeed, my bad. ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf ExecStop=/bin/kill -INT $MAINPID This is asynchronous. The stop operation is supposed to be synchronous however, should not return before it finished. This was modeled after the existing apache2 service file in gentoo systemd overlay, which uses graceful asynchronous stop. If you delete the ExecStop line, systemd will use SIGTERM (non-graceful stop) and wait. That's probably what you want the stop operation to be. OTOH, like it or not, too many existing services don't have any mechanism for synchronous reload and use SIGHUP. I think you should audit all existing service files in Gentoo systemd overlay to ensure that I don't copy any more bad practice. See http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=summary As you noticed, this changes the PID, and systemd currently cannot handle this. We could however reload the PID file after a reload completed I guess. (/me adds this to the todo list) Well, there are cases (live update of nginx, see http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly) where the main PID would change without the explicit systemctl reload command. In the case of nginx, one can follow up the live update with a dummy systemctl reload, so I am not sure if it matters. OTOH, maybe it would be better to evaluate the main PID lazily when it is needed, instead of trying to enumerate all places where it can change and reloading it there. But this way we will also hide all races caused by bad PID file handling logic, so I am not sure. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
18.01.2011 04:48, Lennart Poettering wrote: What systemd currently does is: If the reload fails it shutdowns the service and informs you about the failure. What systemd probably should do (and what is now in the TODO list) is: If the reload fails it should leave the service as is but informs you about the failure. That should make it easy to plug in check scripts via the ExecReload directive and make the need of an additional directive unnecessary. For the case of reloading, you are right. However, the original idea was to run the configuration check also on restart (but not on stop). It is not obvious for me how this can work without a new directive. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assertion failed in systemd v16
hi.. On 01/18/11 13:30, Alexander E. Patrakov wrote: As you noticed, this changes the PID, and systemd currently cannot handle this. We could however reload the PID file after a reload completed I guess. (/me adds this to the todo list) Well, there are cases (live update of nginx, see http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly) where the main PID would change without the explicit systemctl reload command. In the case of nginx, one can follow up the live update with a dummy systemctl reload, so I am not sure if it matters. OTOH, maybe it would be better to evaluate the main PID lazily when it is needed, instead of trying to enumerate all places where it can change and reloading it there. But this way we will also hide all races caused by bad PID file handling logic, so I am not sure. we too use software where the MAINPID changes over time due to automatic/on-the-fly reloading of the main binary.. that is how the on-the-fly logic is implemented: when the modification of the binary is detected - the server will spawn a new main process (new MAINPID) - when successfully initialized - the new process will kill the old one - else (on failure) the old process continues until the next modification is detected systemd is not notified.. i considered issuing a systemctl reload in the main-process to let systemd reload the whole service where ReloadExec would spawn the new instance which kills the old one. But the ReloadExec would never return and so the state of the service would probably be reloading or something and the new MAINPID should be the one of ReloadExec-process.. ..this does not seem to work at all.. how is this supposed to be handled in systemd?? m. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assertion failed in systemd v16
On Tue, 18.01.11 17:30, Alexander E. Patrakov (patra...@gmail.com) wrote: ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf ExecStop=/bin/kill -INT $MAINPID This is asynchronous. The stop operation is supposed to be synchronous however, should not return before it finished. This was modeled after the existing apache2 service file in gentoo systemd overlay, which uses graceful asynchronous stop. If you delete the ExecStop line, systemd will use SIGTERM (non-graceful stop) and wait. That's probably what you want the stop operation to be. OTOH, like it or not, too many existing services don't have any mechanism for synchronous reload and use SIGHUP. Note that you can change the kill signal via KillSignal=SIGHUP or something similar. Well, there are cases (live update of nginx, see http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly) where the main PID would change without the explicit systemctl reload command. In the case of nginx, one can follow up the live update with a dummy systemctl reload, so I am not sure if it matters. OTOH, maybe it would be better to evaluate the main PID lazily when it is needed, instead of trying to enumerate all places where it can change and reloading it there. But this way we will also hide all races caused by bad PID file handling logic, so I am not sure. Hmpf, we actually send out bus notifications when service properties such as the PID change. I figure in weirdo cases like this it would be the nicest solution if the service would just invoke the following when they change PID: sd_notifyf(0, MAINPID=%lu, (unsigned long) getpid()); sd_notify() is defined in sd-daemon.[ch], and may be used to inform the init system about service status changes, include change of the main PID with a command like the above. See sd_notify(3) for details. 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] Assertion failed in systemd v16
On Tue, 18.01.11 14:04, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: hi.. On 01/18/11 13:30, Alexander E. Patrakov wrote: As you noticed, this changes the PID, and systemd currently cannot handle this. We could however reload the PID file after a reload completed I guess. (/me adds this to the todo list) Well, there are cases (live update of nginx, see http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly) where the main PID would change without the explicit systemctl reload command. In the case of nginx, one can follow up the live update with a dummy systemctl reload, so I am not sure if it matters. OTOH, maybe it would be better to evaluate the main PID lazily when it is needed, instead of trying to enumerate all places where it can change and reloading it there. But this way we will also hide all races caused by bad PID file handling logic, so I am not sure. we too use software where the MAINPID changes over time due to automatic/on-the-fly reloading of the main binary.. that is how the on-the-fly logic is implemented: when the modification of the binary is detected I am not a big fan of such a logic for two reasons: a) it's incredible hard to respawn like this if *any* of the loaded code blobs are change (i.e. an app is seldom just a single binary, but uses shared libraries and loadable modules) and b) if multiple things change it is hard to impossible to find the right time where really everything has been fully updated, i.e. you might end up with a half-updated process in the end. - the server will spawn a new main process (new MAINPID) - when successfully initialized - the new process will kill the old one - else (on failure) the old process continues until the next modification is detected systemd is not notified.. I guess in this case too sd_notify(3) could be of help, and the least ugly solution. 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] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
On Tue, 18.01.11 17:56, Alexander E. Patrakov (patra...@gmail.com) wrote: 18.01.2011 16:51, Lennart Poettering пишет: On Tue, 18.01.11 16:41, Alexander E. Patrakov (patra...@gmail.com) wrote: How is this implemented in detail? Sending SIGINT is async, so at the time you start the new instance you cannot be sure that the old instance has stopped listening? Indeed, there is a race here. That's why /bin/sleep 1 in my initial service file. Hmm, what's the lighthttp people's take on this? They came up with the scheme, so how do they think this problem should be handled? They usleep(5 * 1000) and, if the new copy of lighttpd still fails to start due to a race, sleep again and attempt to start it again, ad infinitum. Meh, busy loops like this are equal. (One possible solution could be if the old and the new instance would communicate and pass the listening sockets via some AF_UNIX socket/SCM_RIGHTS or so. But that is not trivial.) I came with a different (albeit systemd-specific) solution. The solution (implemented as an attached patch) is to fork() after we closed all the listening sockets and exit immediately in the parent. This way, the chlid continues to serve already-requested files, and systemd has a race-free indication that it can restart lighttpd via Restart=always. Please review the patch and the service file. One known problem: the patch is completely untested with server.max-worker 0. fork()ing is ugly, will break all mutexes, eat all threads and is otherwise ugly too. Using fork() is in itself a problem, seldom a solution. 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] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
On Tue, 18.01.11 18:00, Alexander E. Patrakov (patra...@gmail.com) wrote: 18.01.2011 04:48, Lennart Poettering wrote: What systemd currently does is: If the reload fails it shutdowns the service and informs you about the failure. What systemd probably should do (and what is now in the TODO list) is: If the reload fails it should leave the service as is but informs you about the failure. That should make it easy to plug in check scripts via the ExecReload directive and make the need of an additional directive unnecessary. For the case of reloading, you are right. However, the original idea was to run the configuration check also on restart (but not on stop). It is not obvious for me how this can work without a new directive. Hmm, so on restart you want to run the check script before the stop operation is run? Hmm, not sure either how to do that best. I guess for that we'd have to add ExecRestartPre= or something like that. 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] miredo unit files
On Tue, 18.01.11 18:34, Alexander E. Patrakov (patra...@gmail.com) wrote: Hmm, I am not sure how miredo works. Is the client something where you have to run one instance per network iface? Or do you have a global instance for all? If the latter, then why doesn't it watch the network interfaces on its own? The client creates its own interface (called teredo, but in fact it is just a tun interface). There cannot be more than one copy of the client, and it should only care about the IPv4 route to the teredo server (by default, teredo.ipv6.microsoft.com) which is often the default route. Hmpf. We live in a mobile world today. It should actively watch the routing table with netlink instead of assuming that an IPv4 connection is unconditionally available. Connections come, connections go, connections are reconfigured. A robust, mobile system must hence be able to watch configuration changes instead of assuming that IP configuration is static like in '95. miredo creates the socket and the teredo interface miredo: hey teredo server, which IPv6 address should I use? kernel drops packet, because there is no route (or, alternatively, DNS doesn't work yet and miredo fails to resolve the IPv4 address of the teredo server) miredo waits a bit, gets upset dhcpcd configures eth0, adds the default route miredo is still upset miredo waits 100 seconds miredo: hey teredo server, which IPv6 address should I use? kernel sends packet teredo server replies So it looks like miredo should reset its timeout when the routing table changes, and that I have to implement this myself. But I have no good tutorial on rtnetlink sockets. libnl is the way to go these days. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
