Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
If we supported PIDFile= for Type=simple, daemons could drop a PID file to indicate startup completion without having to be full-on Type=forking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
'Twas brillig, and David Timothy Strauss at 16/12/13 08:04 did gyre and gimble: If we supported PIDFile= for Type=simple, daemons could drop a PID file to indicate startup completion without having to be full-on Type=forking. Yeah but pidfile is kinda ugly too and has problem when processes are run as other users (requiring corresponding tmpfiles to create appropriately name directores). The amount of code/hassle for proper pid file handling is surely more complex than sd-notify support? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Mon, 16.12.13 00:04, David Timothy Strauss (da...@davidstrauss.net) wrote: If we supported PIDFile= for Type=simple, daemons could drop a PID file to indicate startup completion without having to be full-on Type=forking. There has been a TODO list item for a long time to introduce Type=pid-file which would work like this. I am a bit concerned though that people would just blindly make use of it without actually verifying that their specific daemon really creates the PID file as last part of initialization. But maybe that concern can be dealt with with an explicit warning in the man page. Anyway, I'd be open for such a patch, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
В Sun, 15 Dec 2013 23:23:54 +0100 Lennart Poettering lenn...@poettering.net пишет: This is really not how we should do it: the admin must be capable of tracing and pausing the boot process, and an init system should not make that impossible. What happens currently when service gets SIGSTOP? Does systemd ignore it? Will it reflect this information in service state? Actually, what state service *is* in this case (it obviously is not running but is not failed either ...)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Mon, 16.12.13 06:55, Andrey Borzenkov (arvidj...@gmail.com) wrote: В Sun, 15 Dec 2013 23:23:54 +0100 Lennart Poettering lenn...@poettering.net пишет: This is really not how we should do it: the admin must be capable of tracing and pausing the boot process, and an init system should not make that impossible. What happens currently when service gets SIGSTOP? Does systemd ignore it? We never ask for SIGSTOP notifications, and we hence don't get them at all. Will it reflect this information in service state? No. It really doesn't care much. I am not sure reflecting this information in the service state would really be such a good idea, as the service concept mostly tries to reflect state that applies to all processes of a service, except when it comese to lifecycle decisions. Now, whether a process is stopped or not is really something that is specific to a single process, not a service, so it probably shouldn't be reflected in the entirety of the service. That said, I am not against adding something to the way we display systemctl status where we show explicitly for each process we list whether it is stopped or not. (maybe just by showing unicode stop sign or so next to stopped processes). But sofar nobody asked fr this... Not that we when we kill a service the hard way then we will send a SIGCONT to it, so that we can fulfill the request even if the process is currently stopped. (Because it won't react to SIGTERM as long as it is paused.) Actually, what state service *is* in this case (it obviously is not running but is not failed either ...)? Well, we don't care about whether a process is stopped or not, hence from our perspective whether it is paused or not is indistuingishable, it's just a process like any other, except maybe that it might not respond anymore (which we might notice eventually if watchdog support is enabled for it...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Sat, Dec 14, 2013 at 11:19 PM, Shawn Landden sh...@churchofgit.com wrote: It would be nice if systemd could implement the service supervisor side of the service readiness protocol that upstart calls expect stop: The service doesn't fork, and when considers itself ready it raises SIGSTOP. The supervisor can observe this via the usual mechanisms, being the service's parent, and when it occurs it sends the service CONT and starts whatever was waiting for readiness. The sd_notify(3) protocol is just about tolerable, and it is good that it's documented, but it is quite unattractive for a daemon author: Either they have to add a build- and runtime- dependency on a systemd-specific library, or they have to reimplement a fairly tedious piece of socket code. For a daemon author, raise(SIGSTOP) is lovely and simple. I guess this would be a new Type (but I'm still halfway through the docs so no expert). No, it's not lovely, it's a very cheap and very bad hack. These signals are for admins and not for system management tools; just the same way ptrace is the very wrong tool to track startup behavior of services. It is just so wrong to things like that, and systemd should not do that. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
