Regression introduced in v253 that prevents some units to be restarted

[fbuihuu]

systemd version the issue has been seen with

253

Used distribution

openSUSE Factory

Linux kernel version used

irrelevant

CPU architectures issue was seen on

None

Component

systemd

Expected behaviour you didn't see

Be able to restart auditd.service properly.

Unexpected behaviour you saw

 # systemctl restart auditd.service 
Failed to restart auditd.service: Transaction contains conflicting jobs 'stop' and 'start' for augenrules.service. Probably contradicting requirement dependencies configured.
See system logs and 'systemctl status auditd.service' for details.

Steps to reproduce the problem

# systemctl cat foo.service 
# /etc/systemd/system/foo.service
[Unit]
Requires=bar.service
After=bar.service
PropagatesStopTo=bar.service

[Service]
ExecStartPre=echo start foo
ExecStart=sleep infinity
ExecStopPost=echo stopped foo

# systemctl cat bar.service 
# /etc/systemd/system/bar.service
[Service]
ExecStartPre=echo start bar
ExecStart=sleep infinity
ExecStopPost=echo stopped bar

# systemctl restart foo.service 
Failed to restart foo.service: Transaction contains conflicting jobs 'stop' and 'restart' for foo.service. Probably contradicting requirement dependencies configured.
See system logs and 'systemctl status foo.service' for details.

Note that this test case has been taken from #24068 except that Wants=bar.service was changed into Requires=bar.service.

Additional program output to the terminal or log subsystem illustrating the issue

No response

[fbuihuu]

Regression introduced by commit 017a7ba, hence /Cc @YHNdnzj @poettering

[fbuihuu]

Also note that the test case provided in #24068, where foo.service has Wants=bar.service is also broken because bar.service is not restarted when foo.service is:

# systemctl status foo.service bar.service
● foo.service
     Loaded: loaded (/etc/systemd/system/foo.service; static)
     Active: active (running) since Wed 2023-03-15 18:38:26 CET; 2s ago
    Process: 39993 ExecStartPre=echo start foo (code=exited, status=0/SUCCESS)
   Main PID: 39994 (sleep)
      Tasks: 1 (limit: 1040)
        CPU: 2ms
     CGroup: /system.slice/foo.service
             └─39994 sleep infinity

Mar 15 18:38:26 vm-tw-efi systemd[1]: Starting foo.service...
Mar 15 18:38:26 vm-tw-efi echo[39993]: start foo
Mar 15 18:38:26 vm-tw-efi systemd[1]: Started foo.service.

● bar.service
     Loaded: loaded (/etc/systemd/system/bar.service; static)
     Active: active (running) since Wed 2023-03-15 18:38:26 CET; 2s ago
    Process: 39991 ExecStartPre=echo start bar (code=exited, status=0/SUCCESS)
   Main PID: 39992 (sleep)
      Tasks: 1 (limit: 1040)
        CPU: 2ms
     CGroup: /system.slice/bar.service
             └─39992 sleep infinity

# systemctl restart foo.service 
# systemctl status foo.service bar.service
● foo.service
     Loaded: loaded (/etc/systemd/system/foo.service; static)
     Active: active (running) since Wed 2023-03-15 18:38:40 CET; 2s ago
    Process: 40002 ExecStartPre=echo start foo (code=exited, status=0/SUCCESS)
   Main PID: 40003 (sleep)
      Tasks: 1 (limit: 1040)
        CPU: 2ms
     CGroup: /system.slice/foo.service
             └─40003 sleep infinity

○ bar.service
     Loaded: loaded (/etc/systemd/system/bar.service; static)
     Active: inactive (dead) since Wed 2023-03-15 18:38:40 CET; 2s ago
   Duration: 14.148s
    Process: 39991 ExecStartPre=echo start bar (code=exited, status=0/SUCCESS)
    Process: 39992 ExecStart=sleep infinity (code=killed, signal=TERM)
    Process: 40001 ExecStopPost=echo stopped bar (code=exited, status=0/SUCCESS)
   Main PID: 39992 (code=killed, signal=TERM)
        CPU: 4ms

[poettering]

hmpf, honestly the unit in question is kinda stupid. it encodes a contradiction because it pulls the rug below itself while it is already going down. i am not convinced this really is an issue. And the failure on restart is to be expected then: the Requires= encodes the outcome after a restart is that the depending unit is up, and the PropagatesStopTo= encodes the outcome is down. So what now? the engine correctly detects this and complains.

I am kinda tempted to just say, "don't do that" and move on.

I mean, i understand that older versions of systemd didn't refuse such transactions, but i'd claim thta was a bug we have fixed, and it doesn't constitute a bug we now intrdouced.

[fbuihuu]

Well this is still what auditd.service does and I'm not sure you can blame them to assume that restart is strictly equivalent to stop + start, which is how restart has always been described AFAIK.

My guess is that it's been done this way to automatically restart augenrules.service when auditd.service is.