Thank you for the fast response, Zbyszek!
> > Hi all,
> >
> > I'd like to have your opinion on the following problem:
> >
> > In case a unit fails, we are using an OnFailure unit to
> > handle the error (e. g. reset the config of the failed
> > unit) and restart it.
> >
> > In one case the failed unit had dependencies to other
> > units. Therefore, the failed unit was (re-)started when
> > the other units started.
> >
> > This way, the OnFailure unit was active (which could
> > delete the config), *while* the failed unit, which reads
> > the config, was restarting!
> >
> > Is this behavior intended or could it be an advantage to
> > let a unit "conflict" to its OnFailure unit in some way?
> Yes, it's intended.
>
> > A first idea for a workaround is to add an "After"
> > dependency to the OnFailure unit in the real unit's
> > service file. This way a job for the unit should be
> > created but the unit would not start until the
> > OnFailure unit finbished. Is this correct?
> That's should work.
>
> Zbyszek
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
