On Thu 20 Dec at 12:46:14 +0100 lenn...@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.pep...@linux.intel.com> Intel Open Source Technology Centre _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
