On 09/01/2011 07:45 PM, Lennart Poettering wrote:
On Thu, 01.09.11 16:03, "Jóhann B. Guðmundsson" (johan...@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?

JBG

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to