Bug#1081780: systemd: OnSuccess, Conflicts does not work correctly when the unit restarts after an error

[Zoltán Krajcsovics]

Package: systemd
Version: 252.30-1~deb12u2
Severity: normal

OnSuccess does not work correctly, likely since after the "activating
(auto-restart)" state, the unit enters the "inactive" state
momentarily.

If the Conflicts option is added, the conflicting units are started
and stopped together.


To demonstrate the problem, the file

conflict_onsuccess.report.tar.bz2

is attached, though it will only work in

~/prg/systemd/

(for other locations, the paths must be changed)

Here I tried to outline the tests I made with the attached setup:

1)

Test setup:
===========

unit_1 configured with:

OnSuccess=unit_2.service
StartLimitIntervalSec=1000
StartLimitBurst=3
Restart=on-failure
RestartSec=5

unit_1::ExecStart:
sleep 10

unit_1::ExecStartPost:
exit -1

unit_1::ExecStopPost:
sleep 4

unit_2::ExecStart:
sleep 10

Result:
=======

unit_1 start
unit_1 fail
unit_1 stop
unit_1 stop_post, sleep 4

restart, sleep 5

unit_1 is started alongside with unit_2, unit_2 sleeps 10s, then next time
unit_1 is started, unit_2 is started, as well.
Expected:
=========

unit_2 never starts.


2)

If we add Conflicts to unit_1 or unit_2, the behaviour is even more different
from the expected.

Test setup:
===========

unit_1 configured with:

OnSuccess=unit_2.service
StartLimitIntervalSec=1000
StartLimitBurst=3
Restart=on-failure
RestartSec=5
# !!!
Conflicts=unit_2.service

unit_1::ExecStart:
sleep 10

unit_1::ExecStartPost:
exit -1

unit_1::ExecStopPost:
sleep 4
Result:
=======

unit_1 start
unit_1 fail
unit_1 stop
unit_1 stop_post, sleep 4

restart, sleep 5

unit_1 is started alongside with unit_2, and stopped alongside unit_2.
After unit_1 initially enters the auto-restart state, the starting and
stopping of unit_1 and unit_2 is synchronized, they are started and
stopped at the same time.

Expected:
=========

unit_2 never starts.

unit_2 does not run at the same time as unit_1, contrary to the Conflicts
option.


3)

If the Conflict option is set in unit_2, as well, the expected behavior is
observed:

unit_2 is never started.


4)

If we add OnFailure to the unit_1 service file:

unit_1 start

unit_1 auto-restart --- unit_2 start
unit_1 stop -- unit_2 stop
unit_1 auto-restart --- unit_2 start
unit_1 stop -- unit_2 stop
...

unit_1 reaches StartLimitBurst, and enters failed state

contrary to OnFailure, unit_2 is _not_ started at this moment, but
wait unit_1::RestartSec and then

unit_2 start
sleep 10sec
unit_2 stop


5)

If both unit_1 and unit_2 have the Conflicts option set with the other unit

unit_1.service::Conflicts=unit_2.service
unit_2.service::Conflicts=unit_1.service

and unit_1 sets both OnSuccess and OnFailure:

unit_1.service::OnSuccess=unit_2.service
unit_1.service::OnFailure=unit_2.service

Then unit_2 won't be started until the unit_1 restart regiment is over, and
then will unit_1 be started. This was the only time the expected behaviour
was observed.

======
Sumary
======
At first glance, it seems as though there is a glitch in the state of unit_1
before the auto-restart mechanism restarts the unit.

However, bringin in the Conflicts option, it seems that the unit_1 config is
somehow influencing unit_2.

Furthermore, the behaviour is more like as it the 2 units were bound together,
starting and stopping simultaneously, the exact opposite what I would expect.


-- Package-specific info:

-- System Information:
Debian Release: 12.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Best regards,
Zoltan.K.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conflict_onsuccess.report.tar.bz2
Type: application/x-bzip
Size: 1710 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240914/1f40fc39/attachment.bin>