Systemd tries to start some services repeatedly after failing condition check

[hexchain]

systemd version the issue has been seen with

v245.4

Used distribution

Arch Linux

Expected behaviour you didn't see
These services are executed only once, and if they fail condition check, they might only be restarted once the conditions are changed.

Unexpected behaviour you saw
Some services that are probably supposed to execute only once are constantly being started, despite failing condition check every time.

Such services include:

systemd-machine-id-commit.service
systemd-firstboot.service
systemd-boot-system-token.service
systemd-pstore.service

Relevant logs (generated with journalctl -b _PID=1 _COMM=systemd | grep 'Condition check resulted in' -A2 -B2):

https://paste.xinu.at/Ltc

Steps to reproduce the problem
It happens all the time.

[jdebp]

Compare https://unix.stackexchange.com/q/578331/5132 .

[mbiebl]

looks like another duplicate / instance of #15091 , i.e. a result of 097537f.

[hexchain]

The conclusion there seems to be adding RemainAfterExit=yes to affected services, but I'm not sure how that applies to services that have failed condition check.

(Didn't test, this is just a guess)

[anitazha]

The services you listed do have RemainAfterExit=yes so it could be another bug or at least another corner case to 097537f

[hexchain]

Those services failed condition test so they were not activated/executed at all. I guess RemainAfterExit is irrelevant here?

[hexchain]

Here are some systemd debug logs when pressing XF86BrightnessUp/Down key in Plasma (which then calls org.kde.powerdevil.backlighthelper over system bus):
https://paste.xinu.at/TBqUY/
https://paste.xinu.at/m4Mi/

It seems to me that systemd is trying to walk the whole dependency tree and start everything that is not already active, despite those dependencies themselves are activated. Is this expected?

[keszybz]

This seems to be the same as #15188. Unfortunately all the pastebin logs are not available anymore, so it's even hard to say what the original issue was. In the fututure, please paste the logs directly in the issue (or attach, if they are very long).