Ewoud Kohl van Wijngaarden writes:
> On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:
>> Ewoud Kohl van Wijngaarden writes:
>>
>>> On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:
>>>> The only thing that https://docs.fedoraproject.org/en-US/packaging-
>>>> guidelines/Scriptlets/ tells me to do is to put %systemd_postun_with_restart
>>>> in my %post. However:
>>>>
>>>> 1) systemd complains that it wants a daemon-reload, in order to pick up an
>>>> updated .service file
>>>>
>>>> 2) I still must manually run systemctl reload-or-restart --marked, in order
>>>> to actually restart an updated service
>>>>
>>>> It seems to be there's a missing step, in here. By comparison I prepared
>>>> comparable .deb packages for Ubuntu, using dh_installsystemd in the install
>>>> script. The end result:
>>>>
>>>> A) The initial .deb install enabled and started the service.
>>>>
>>>> B) Bumping the release, rebuilding, and installing the newer package results
>>>> in an automatic daemon-reload and restart, restarting the service.
>>>>
>>>> Overall .deb's systemd integration seems to go smoother (compared to the
>>>> rest of the .deb packaging process) than rpm's.
>>>>
>>>> Is there a specific reason why %systemd_postun_with_restart stops before
>>>> finishing the job? Am I missing something that I can install, to have this
>>>> happen auto-magically?
>>>
>>> I think daemon-reload changed to file triggers in systemd 228:
>>>
>>> https://github.com/systemd/systemd/commit/
>>> 873e413323dfff4023604849c70944674ae5cd29
>>>
>>> However, the scriptlets documentation[1] states to use %systemd_post with
>>> %post and %systemd_postun_with_restart with %postun. %Perhaps that you're
>>> using %systemd_postun_with_restart in %post is the source of your problems?
>>
>> No, my invocation is in %postun. Furthermore, it wouldn't matter, since at
>> %post time the new package and the new service unit should already be
>> installed and restartable.
>>
>> And, as I wrote:
>>
>>>> 1) systemd complains that it wants a daemon-reload, in order to pick up an
>>>> updated .service file
>>
>> If ot was "changed to file triggers", well, it's not working since nothing
>> is getting triggered. Furthermore, %systemd_postun_with_restart runs:
>>
>> /usr/lib/systemd/systemd-update-helper mark-restart-system-units
>>
>> which does:
>>
>> systemctl set-property "$unit" Markers=+needs-restart &
>>
>> That's all it does. Then, as I wrote:
>>
>>>> 2) I still must manually run systemctl reload-or-restart --marked, in order
>>>> to actually restart an updated service
>>
>> So, the shipped systemd scriptlets are still, very much, under an impression
>> that explicit action needs to be taken to restart and/or reload
>> updated .services. But, nothing gets reloaded. The .service files gets
>> marked for a restart, but, from what I can tell, nothing ever gets restarted.
>
> Do you happen to have the spec file and/or the RPMs? How can we replicate
> the findings?
Take the following spec file, below, and just feed it to rpmbuild -ba.
Then, rpm -ivh the binary rpm. Then:
systemctl enable testsystemd
systemctl start testsystemd
systemctl status testsystemd
You'll get something like this:
[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;
vend>
Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 10s ago
Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 88834 (code=exited, status=0/SUCCESS)
CPU: 2ms
Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.
Up to now, everything looks good.
Now, take this spec file, bump the release, feed it to rpmbuild again.
According to my best understanding of systemd's published documentation:
installing an updated package should automatically restart the active
service, shouldn't it?
But after I fed the new version to rpm -UvhF, what I got was:
[mrsam@jack tmp]$ systemctl status testsystemd | cat
Warning: The unit file, source configuration file or drop-ins of
testsystemd.service changed on disk. Run 'systemctl daemon-reload' to reload
units.
● testsystemd.service - testsystemd
Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;
vendor preset: disabled)
Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 4min 35s ago
Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 88834 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 76902)
Memory: 0B
CPU: 0
CGroup: /system.slice/testsystemd.service
Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.
A loud complaint at the beginning that systemd wasn't reload. Same,
unchanged, syslog timestamp from the initial start.
This is on up to date F35.
Then, at this point:
sudo systemctl daemon-reload
sudo systemctl reload-or-restart --marked
[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;
vend>
Active: active (exited) since Mon 2022-03-21 19:08:29 EDT; 26s ago
Process: 89032 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 89032 (code=exited, status=0/SUCCESS)
CPU: 1ms
Mar 21 19:08:29 jack systemd[1]: Starting testsystemd…
Mar 21 19:08:29 jack systemd[1]: Finished testsystemd.
Now, everything is normal, and new syslogs showing a restart.
So, as far as I can tell: %systemd_postun_with_restart did not restart
anything.
Name: testsystemd
Version: 1
Release: 3%{?dist}
Summary: Test
License: GPL
%description
%prep
%build
%install
mkdir -p $RPM_BUILD_ROOT/lib/systemd/system
cat >$RPM_BUILD_ROOT/lib/systemd/system/testsystemd.service <<EOF
[Unit]
Description=testsystemd
[Install]
WantedBy=multi-user.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/bin/true
EOF
%post
%systemd_post testsystemd.service
%preun
%systemd_preun testsystemd.service
%postun
%systemd_postun_with_restart testsystemd.service
%files
/lib/systemd/system/*
I wonder if this behaves the way it does because you're using a oneshot service as an example here? It exits as soon as it starts, so there is not even a running process to "restart" on package upgrade.
Fabio