[systemd-devel] Restart and RestartSec in packaged .service files

"Jóhann B. Guðmundsson" johannbg at gmail.com
Thu Sep 1 13:13:26 PDT 2011

On 09/01/2011 07:45 PM, Lennart Poettering wrote:
> 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
> systemd.
> 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.

Hum not following here the path unit would support restarting/reloading 
the unit file as opposed to only starting it.

For instance you would add apache vhost.conf, configure a path unit to 
trigger restart/reload when the configuration file appears in the 
specified directory.

>> 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.

Hum would not the system logger handle rotation and stuff?


More information about the systemd-devel mailing list