[systemd-devel] directive for executing a script on service failure

[Lennart Poettering]

On Fri, 06.02.15 21:23, Mantas Mikulėnas (grawity at gmail.com) wrote:

> On Fri, Feb 6, 2015 at 5:26 PM, George Karakougioumtzis <
> mad-proffessor at hotmail.com> wrote:
> 
> > Hi. Congrats for the near perfect job on systemd! I was searching for a
> > directive to execute a script upon systemd service failure. I would like
> > to receive desktop notifications about such  failures. I stumbled upon
> > OnFailure and FailureAction but these have hardcoded list of actions?
> 
> One of those actions is "start an arbitrary unit", which could handle
> notifications... Unfortunately it doesn't actually pass any failure
> information to that unit. 
>
> So, instead, you might have to watch the system
> log (journal) for unit failure notices. (I would normally have said that
> the journal makes it easy to filter for them, but quite strangely, these
> ones don't have a MESSAGE_ID attached...)

if you use OnFailure= I'd recommend checking the properties of the
unit that failed instead of checking the journal. i.e. the equivalent
of "systemctl show -p ..." on the unit that failed...

And yeah, we should define a MESSAGE_ID for unit failure log messages.

> > Any hints how to get notified (with notify-send most likely)?
> 
> systemd calling notify-send isn't going to happen – as a service, it runs
> "outside" your desktop session, and has no access to its D-Bus session bus,
> which tends to be started at a random address. (There might even be several
> sessions, not just one!) And even considering the future "user bus" plans
> (which would put the session bus at a known fixed location), the whole idea
> of having a service inject something into a desktop session is really ugly.
> Even Microsoft realized that and implemented "session 0 isolation"
> in VIsta.

Yes, that's correct. We do not call from lower layers into higher
layers in systemd. Higher layers should instead subscribe to lower
layers...

> In other words, such a notifier would need to be started from within your
> desktop session, connect *to* systemd (either by waiting for signals on the
> system bus or by watching the journal messages), and idle in background
> waiting for some unit to fail. With DBus it could be a simple 10-line
> script, waiting for signals on one bus and calling Notify() on another...

Another option would be to write a clinet that watches the journal
constantly, and pops up a notification each time a message with
LOG_ERR and higer is sent. After all, not only service errors should
be interesting, all other errors should matter too..

Lennart

-- 
Lennart Poettering, Red Hat