Zbigniew Jędrzejewski-Szmek writes:
There are two separate steps here: "daemon-reload" and "restart testsystemd.service". Systemd is complaining about "daemon-reload" missing. It isn't internally cognizant of the fact that testsystemd.service should be restarted, that is managed by the rpm scriptlets and "needs-restart" markers. Internally, it just looks at the file timestamps and knows that it has old config. RemainAfterExit=true means that the service is pinned even though it exited, so systemd remembers the old config of the service from before the upgrade and hence the complaint. The warning goes away after "daemon-reload".
The point is: WHY is there no daemon-reload?The timestamps are going to get updated, as a result of theupgrade, whether the service is oneshot, or whatever. It doesn't matter.
This is the only thing that the systemd %postinst script inserts into the rpm:
if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then # Initial installation/usr/lib/systemd/systemd-update-helper install-system-units testsystemd.service || :
fi And this is the postinstall script: if [ $1 -ge 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then # Package upgrade, not uninstall/usr/lib/systemd/systemd-update-helper mark-restart-system-units testsystemd.service || :
fiLooking at that, and at what's in /usr/lib/rpm/macros.d/macros.systemd, I see absolutely nothing that will execute a daemon-reload after an rpm update.
To me, it's seem rather obvious that an rpm update should trigger, in some form or fashion, a daemon reload. Either that, or systemctl should stop complaining about a daemon reload.
Note that this is separate from the fact that there's no restart, either. There are two issues here: no reload, and no restart.
That the service is "oneshot" matters for the "restart" part. What systemd actually does, is queue a "try-restart" job for the marked units. Since this service is not running, that should become noop. There seems to be a bug in the implementation though: try-restart always restarts the unit → https://github.com/systemd/systemd/issues/22850.
Are you saying that if it wasn't a oneshot service, it would get restarted?That's weird. Because I have a Type=forking service right here that doesn't get restarted either.
My oneshot example was merely the most convenient reproducer that I could whip up on a moment's notice.
As far as I can tell, it doesn't matter what the service type is, forking or not, it does not get restarted. It merely gets marked, and I must manually run systemctl reload-or-restart --marked in order to actually restart it. I see nothing in the scriptlets that will do it for me.
Attachment:
pgpV3eEs8KiL8.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
