No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

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?

[Ewoud Kohl van Wijngaarden]

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/873e413323dfff4023604849c709446...

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?

[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy...

[Sam Varshavchik]

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.

[Ewoud Kohl van Wijngaarden]

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?

[Sam Varshavchik]

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/*

[Ewoud Kohl van Wijngaarden]

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

[Sam Varshavchik]

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.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 23, 2022 at 05:55:19PM +0100, Ewoud Kohl van Wijngaarden wrote:
>  On Mon, Mar 21, 2022 at 07:12:23PM -0400, Sam Varshavchik wrote:
>  > %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 suspect that the path may be an issue. The transfiletrigger in
systemd is matched on /etc/systemd/system, /usr/lib/systemd/system,
and as far as I know, /usr/lib/systemd/system and /lib/systemd/system
are different paths as far as rpm is concerned. %{_unitdir} should be used
instead of /lib/systemd/system/.

Zbyszek

[Fabio Valentini]

On Tue, Mar 22, 2022, 00:12 Sam Varshavchik <mrsam(a)courier-mta.com&gt; 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 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


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 24, 2022 at 08:38:39AM +0100, Fabio Valentini wrote:
>  On Tue, Mar 22, 2022, 00:12 Sam Varshavchik
> <mrsam(a)courier-mta.com&gt; wrote:
>  > [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. 
>  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. 
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".

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.

Zbyszek

[Sam Varshavchik]

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?

The timestamps are going to get updated, as a result of theupgrade, whether  
the service is oneshot, or whatever. It doesn't matter.

This is the only thing that the systemd %postinst script inserts into the  
rpm:

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

And this is the postinstall script:

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

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.

To me, it's seem rather obvious that an rpm update should trigger, in some  
form or fashion, a daemon reload. Either that, or systemctl should stop  
complaining about a daemon reload.

Note that this is separate from the fact that there's no restart, either.  
There are two issues here: no reload, and no restart.

>  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?

That's weird. Because I have a Type=forking service right here that doesn't  
get restarted either.

My oneshot example was merely the most convenient reproducer that I could  
whip up on a moment's notice.

As far as I can tell, it doesn't matter what the service type is, forking or  
not, it does not get restarted. It merely gets marked, and I must manually  
run systemctl reload-or-restart --marked in order to actually restart it. I  
see nothing in the scriptlets that will do it for me.

[Zbigniew Jędrzejewski-Szmek]

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

[Sam Varshavchik]

Zbigniew Jędrzejewski-Szmek writes:

>  > > 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 ;) 
Well, I got one restart in the bag, now. Whether I'll end up with too many  
restarts, that's something that only future will tell...

But this problem was very hard to see:

lrwxrwxrwx. 1 root root 7 Jul 21  2021 /lib → usr/lib

Having a package install its service file via /lib broke these triggers. And  
there was no outward sign that there was anything wrong. The service stops  
fine, and it starts just fine. Only a reload or a restart does not work and  
there's no blinking sign anywhere that tells you what's wrong, exactly.

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 25, 2022 at 07:07:22PM -0400, Sam Varshavchik wrote:
>  Zbigniew Jędrzejewski-Szmek writes:
>  
>  > > > 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 ;)
>  
>  Well, I got one restart in the bag, now. Whether I'll end up with too many
>  restarts, that's something that only future will tell...
>  
>  But this problem was very hard to see:
>  
>  lrwxrwxrwx. 1 root root 7 Jul 21  2021 /lib → usr/lib
>  
>  Having a package install its service file via /lib broke these triggers. And
>  there was no outward sign that there was anything wrong. The service stops
>  fine, and it starts just fine. Only a reload or a restart does not work and
>  there's no blinking sign anywhere that tells you what's wrong, exactly. 
Our packaging guidelines say to use %{_unitdir} i.e. /usr/lib/systemd/system,
so this problem is unique to your custom package.

I think it might be reasonable to add non-usr-prefixed paths to the
transfiletriggers path lists to make this more robust for "foreign" packages.
I'll try to submit a patch upstream.

Zbyszek