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.
conflict_onsuccess.report.tar.bz2
Description: application/bzip
