[systemd-devel] ExecRestart

[Colin Guthrie]

'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 (blblack at 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/