> On 24 Mar 2022, at 01:07, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote: > Ewoud Kohl van Wijngaarden writes: > >> 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). > > I have systemd-rpm-macros installed. I'm not using mock, I'm just building natively. > >> After I see (as I would expect): > > Same here. These systemd scripts are getting picked up and packaged into the rpm, too. > > But neither here, nor there, do I see anything in these scripts that actually restarts anything. The %postun script does mark, via systemd-update-helper, the service for restart, but it does not get restarted. > > So, when you say that you couldn't reproduce it, I just want to make sure that you meant: > > 1) Before installing the updated package, "systemctl status testsystemd" shows that the test service was started > > 2) After installing the updated package, the same, and the start timestamp has updated, and there's no complaint about needing a daemon-reload? > > If so, then there must be a missing dependency somewhere. Something outside of this script must be taking care of running daemon-reload and restart --marked, and I don't have it installed. These scripts sure aren't doing any of that, themselves. Is it because you use rpm and not dnf? I have always thought that it was necessary to use dnf (or yum on older systems) to have the things installled and tracked correctly. Can you use mock to build your RPM to ensure that the build does not depend on side effects from what is installed on your system. Barry > > _______________________________________________ > 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
Attachment:
mime-attachment
Description: Binary data
_______________________________________________ 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
