'Twas brillig, and Daniel P. Berrange at 20/12/12 10:44 did gyre and gimble: > On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote: >> On Wed, 28.11.12 22:41, Brandon Black (blbl...@gmail.com) wrote: >> >>> The daemon's "fast restart" code does all of the expensive startup >>> operations in the new daemon first (e.g. parsing large data input), then >>> signals the existing daemon to shut itself down, waits for it to release >>> its critical resources (e.g. sockets, pidfile), and finally takes over >>> those resources and finishes starting itself. Basically it's using the >>> overlap to avoid long service downtimes during that initial parsing phase >>> (and if that parsing fails, it leaves the old daemon running to boot). > > [snip] > >> Or in other words: >> >> I am pretty sure that we should not alter the current restart logic, and >> should not introduce ExecRestart=. However, we really should think about >> either introducing ExecReexec= or somehow making ExecReload= useful for >> reexec-style reloading, too. But I haven't made my mind up on this, how >> this could look like. > > FWIW, as previously mentioned, I'd love to see an explicitly supported > way to trigger a re-exec of a daemon. Currently I'm just relying on the > ability to send a custom signal to libvirt's virtlockd daemon. The problem > is that sysadmins would need to learn a different signal number for each > project's daemon. So I think there's value to admins in having a standard > way to trigger this via sysadmin. Personally I think this should also be > separate from ExecReload which is merely used to refresh configuration > files.
Hmmm, this gives me a small idea. I've had a few users report similar things on different projects, e.g. one user complained that they used to use: service httpd closelogs but with systemd that no longer worked. Perhaps rather than trying to define a whole new language here we could instead define some generic way to send signals to a "unit" (obviously just to the main pid really) and some kind of nice way to cosmetically rename signals. e.g.: SignalMap=closelogs=HUP reexec=USR1 Then you could simply run: systemctl signal closelogs httpd.service Or something similar. Keeps things fairly defined still, but also gives a reasonable amount of flexibility. Of course running "systemctl signal HUP httpd.service" should also be supported and the SignalMap is really just a lightweight wrapper for cosmetic purposes. (this doesn't solve all the problems I've had reported of "random" verbs being used in initscripts. e.g. IIRC the postgres initscript had an "initdb" verb... this won't be solvable via this mechanism, but I don't think there is really a desire to allow ad-hoc verb registration in units with custom "ExecVerb[initdb]=/usr/bin/..." style syntax - I could be wrong tho'. FWIW Specifically in the postgres case I think it can be solved differently anyway with an ExecStartPre that checks to see if the db is init'ed and if not runs and init routine - that's how our mariadb stuff works these days I think and it seems robust enough) 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