apply-live: list affected service files, maybe (add option to) restart them right away

[djasa]

Host system details

# rpm-ostree status
State: idle
AutomaticUpdates: check; rpm-ostreed-automatic.timer: inactive
Deployments:
● fedora:fedora/37/x86_64/silverblue
                  Version: 37.20220906.n.0 (2022-09-06T08:36:28Z)
         BootedBaseCommit: 2cfef8552499fe6106828b6ae0047cf9e56308cc68e0a4210fa8218cc822cc9b
                   Commit: 5310d1f7ae41264cb59f2c1b79a9d2ce08640d1cd69ee1bf997017c5298db238
               LiveCommit: 0bc79658904c0a36b00c0d89854eb77ae4c539287ca7bdab0619ebef7ebf1fa5
                 LiveDiff: 1 upgraded
             GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
           LocalOverrides: NetworkManager-wwan NetworkManager-libnm NetworkManager-adsl NetworkManager NetworkManager-config-connectivity-fedora NetworkManager-ppp NetworkManager-wifi NetworkManager-bluetooth 1:1.39.90-1.fc37 -> 1:1.40.0-1.fc37
                           wireplumber wireplumber-libs 0.4.11-3.fc37 -> 0.4.11-4.fc37
          LayeredPackages: ansible git gnome-tweak-tool guestfs-tools htop ipa-client krb5-workstation libguestfs libguestfs-xfs libvirt-client libvirt-daemon openssl perl-Git qemu-system-x86 tlp vim-enhanced virt-viewer
                 Unlocked: transient
# rpm-ostree --version
rpm-ostree:
 Version: '2022.12'
 Git: 711661acda4ca51a1f26810c29ccb8d9ca53f12f
 Features:
  - rust
  - compose
  - fedora-integration

Expected vs actual behavior

Run:

rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-10d21445e7 # try NetworkManager in testing as of writing of this issue
rpm-ostree ex apply-live --allow-replacement

Actual (writing from top of my head):

...
Some services need to be restarted for update to take full effect

Expected: rpm-ostree lists added or modified service files giving user clue what needs to be restarted or if it is maybe better to reboot. Optionally, apply-live could have something like --restart-services and/or --start-services arguments to do this for the users (restart is probably incontroversial, start of services in default configuration may be easily undesired. IMO).

I see something like this mentioned in announce of release 2022.13 so this is just a bit of elaboration on the topic.

Steps to reproduce it

Would you like to work on the issue?

just testing

[cgwalters]

Yeah, a ton of stuff to do here potentially. Happy to mentor someone on this!

[djasa]

Yeah, a ton of stuff to do here potentially. Happy to mentor someone on this!

I'm using rpm-ostree more heavily since last week due to recovery of system from FS corruption and some workflow changes so I at least dumped here what would IMO make rpm-ostree more pleasant tool to work with (which is IMO important because people are more likely to need this when they are totally new to rpm-ostree-based systems).

However having #3994 implemented or not is something that may be difference between people loving Silverblue (Kinoite, ...) for helping them out of difficult situation or abandoning it full of frustration from inability to do anything nor having any online clues.

[lucab]

Just for clarity, the above mentioned FS corruption is not strictly relevant to the feature request by itself.

[cgwalters]

The way I think about this, we're effectively breaking the bit of logic that lives (hmm, somewhere?) that invokes systemctl daemon-reload after systemd units are updated. Ah OK, I think I found it...let's take https://src.fedoraproject.org/rpms/rtkit/blob/rawhide/f/rtkit.spec#_75 as a random example. That expands to:

$ rpm -q --scripts rtkit
...
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 rtkit-daemon.service || : 
fi

Basically because we're uninstalling the old version, that mark-restart-system-units I think will queue a systemctl daemon-reload.

One approach we could take here is to either hook into or intercept /usr/lib/systemd/systemd-update-helper mark-restart-system-units and queue it in memory.

But, eh. Also, that only helps for RPM content.

So I think what I'd vote here is that we do a filesystem-level diff between the running and new filesystem tree, and if we see anything in /usr/lib/systemd/system as changed, then we invoke systemctl daemon-reload on our own. We can also print out a list of modified units to possibly restart.