On Mo, 08.10.18 09:58, Jérémy Rosen (jeremy.rosen@xxxxxxxx) wrote: > > > This all makes me wonder whether a different approach to all of this > > wouldn't be better: maybe we should just consider this a logging > > problem: let's make sure we log a recognizable log message (i.e. a > > structured journal message with a well-defined MESSAGE_ID=) whenever a > > service fails. With that in place it should be relatively easy to > > write a system service that can run during regular system uptime and > > can look in the journal for all failures, including getting live > > notifications when something happens. Moreover, this resolves the > > problems during early and late boot: the "cursor" logic of the journal > > allows such a service to know exactly which failures it already > > processed and which ones are still left, and it can process all > > failures that took place while it was not running. > > > > Does that make sense? > > Could this be generalized to "a structured message whenever a unit changes > state" or would that be too verbose ? We have that already but only in debug logging mode (systemd-analyze log-level debug). It's a bit too much noise to turn on by default otherwise... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel