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
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
