Re: No daemon-reload or restart with %systemd_postun_with_restart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 21, 2022 at 07:12:23PM -0400, Sam Varshavchik wrote:
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 couldn't reproduce it, but I also made some changes to use more macros. I added BuildRequires: systemd-rpm-macros. Perhaps that was at least the missing piece. Then I also used %{_unitdir} instead of /lib/systemd/system/ (and %{buildroot} instead of $RPM_BUILD_ROOT, but that shouldn't matter).

After I see (as I would expect):

$ rpm -q --scripts /var/lib/mock/fedora-35-x86_64/result/testsystemd-1-3.fc35.x86_64.rpm
postinstall scriptlet (using /bin/sh):

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
preuninstall scriptlet (using /bin/sh):

if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then # Package removal, not upgrade /usr/lib/systemd/systemd-update-helper remove-system-units testsystemd.service || : fi
postuninstall scriptlet (using /bin/sh):

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 || : fi
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux