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