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