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 ? I'm asking because that would be very usefull for post-mortem diagnostics, statup timings and that sort of stuff... Lennart --
|
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
