On Fri, 06.02.15 21:23, Mantas Mikulėnas ([email protected]) wrote: > On Fri, Feb 6, 2015 at 5:26 PM, George Karakougioumtzis < > [email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
