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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
