[systemd-devel] ExecRestart

[Timothy Pepper]

On Thu 20 Dec at 12:46:14 +0100 lennart at poettering.net said:
>
> This is actually documented explicitly, that we don't support this:
>
> http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
>
> And I am pretty strongly of the oppinion that service-specific verbs
> should not be handled in systemd, since there is no need for it and for
> much of the verbs you really don't want systemd in the game.

Not intending to argue the need for arbitrary verbs (don't think that
route is desirable/necessary), but I've been kicking the following use
case around my head for a while:

I'd like to have systemd automatically restart my daemon on failure
(ie: Restart=on-failure) in a controlled way (ie: StartLimitInterval and
StartLimitBurst) and have the daemon aware of how it is doing relative
to the start limit controls.

I might be satisfied with something like an
StartLimitAction=Exec=/path/to/daemon/reseter action.  And I could
undoubtedly also cobble something equivalent together with additional
unit files and scripts that do management actions, OnFailure=, track
restart counts and do 'systemctl reset-failed' calls.  Or an OnFailure
variant which is only triggered at the StartLimit being hit, but then
that overloads the idea of failure relative to Restart=on-failure.
All of these feel kludgy to me as systemd is already capable of pretty
sophisticated management of my daemon and I just want some insight into
what's happening one level up.

> Signals are really not useful for this as they are asynchronous. I am
> pretty sure that we should push people towards implementation of these
> verbs in a way that they can rely that the operation finished after
> systemctl returned. By adding special support for signals for these
> things we'd push people to make these things racy, but we really should
> try to push people to make them synchronous and hence non-racy by default.

I'm inclined to think what I'd really like are some environment variables
passed to me along the lines of how WATCHDOG_USEC informs an executed
service process for WatchDogSec.  Such variables would allow my code
and systemd to have some shared configuration context just as there is
shared context with respect to the watchdog.

Along those lines, could env variables similarly be used to give
a daemon some start context (eg: cold start, full restart, quick
restart), allowing it some latitude to do custom things if it wanted?

But then unless sufficiently generic this also just starts becoming a
generic verb support mechanism...


-- 
Tim Pepper <timothy.c.pepper at linux.intel.com>
Intel Open Source Technology Centre