On Thu, 20.12.12 11:37, Colin Guthrie ([email protected]) wrote: > > 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.
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. For example apache init scripts frequently have a "configtest" or "info" verb, which does some apache specific stuff, but where you really don't want all the magic of systemd with detached ttys and things, because you actually want the output on the local tty. If we add more service verbs to systemd, then we should only do that for verbs that many will actually implement, i.e. which are abstract enough for people to use more widely. > 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. 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. > Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
