[systemd-devel] Restart and RestartSec in packaged .service files
lennart at poettering.net
Thu Sep 1 12:45:14 PDT 2011
On Thu, 01.09.11 16:03, "Jóhann B. Guðmundsson" (johannbg at gmail.com) wrote:
> On 09/01/2011 02:13 PM, Lennart Poettering wrote:
> >We currently store information about crashes in syslog, which is however
> >not really that helpful.
> >I do believe however that we really need to work towards the direction
> >that we can auto-respawn services where this makes sense by default and
> >have a nice way to store away informatoin about the failure, so that
> >this is not lost.
> I do believe the proper saner result would be defaulting to
> on-failure instead and distro's be left up to add to their unit
> files where applicable auto-respawn on servers it's really not what
> you want.
> Now there are two reasons we admins need to restart services
> 1) Because it failed or is left in some
> And we already have in place restart on failure to handle that
> 2) Because we made some configuration changes
> Path units can be used to handle that which is why I filed that RFE
> to extend it a bit then we would not even have to bother with
> restarting the service ourself or write some script to do that if
> that configuration file was synced/pushed/pulled over the network or
> changed locally
I am really not much of a friend of automatic configuration
reloading. One shouldn't really consider configuration files as solitary
elements which change isolated from everything else. Instead, they tend
to be updated in conjunction with a lot of stuff, that might be
interlinked. For example, in systemd you usually update a .service file
in conjunction with a .path file and a .socket file and it would be a
bad idea to reload PID 1 in between, which is why we don't do that in
In some cases it might make sense to automatically reload the
configuration file, but since this requires some insight into the code
and its semantics it's probably best to have the developers add support
for automatic configuration reloading into the daemons themselves, and
not try to bolt it on from the outside.
In other words: if automatic configuration reloading is done this is
something to implement in the daemons themselves, not via .path units.
> I would think that all systemd would have to do would be to log the
> action, flag it failure or path change/restarted by user or another
> unit with timestamps to something like /var/log/systemd.log which
> other ( logger ) tools could be used to parse that log and have the
> ability to notify some external system with that same information.
I am not sure we should create our own logging system for this. Rotation
and suchlike doesn't like a fun job to do.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel