[systemd-devel] Default on failure dependencies

[Jérémy Rosen]

> 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.rosen at smile.fr <mailto:jeremy.rosen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20181008/e10c5289/attachment.html>