On Thu, Mar 24, 2022 at 07:51:11PM -0400, Sam Varshavchik wrote:
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?
See my other mail about the unit file path. Did you try with the correct path?
Looking 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.
There are transfiletriggers to do this: see 'rpm -q --filetriggers systemd | less
+/system-reload'
> 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?
No. I'm saying that oneshot services get restarted even if they shouldn't
due to a bug. So once you fix the path, I expect that you'll go from
no-restarts to sometimes-too-many-restarts ;)
Zbyszek