[Rpm-maint] F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Florian Festi]

On 7/29/21 11:51 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 29, 2021 at 09:37:53AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>> On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote:
>> So... personally I think we should restart many more things than
>> we currently do. Even in systemd itself we fall short of this
>> goal: systemd-logind is not restarted because of bugs (gnome
>> session gets killed when logind is restarted, and it's really a
>> problem with how logind manages resources during restart [1]).
>> To be able to safely restart, the application has to provide the
>> appropriate functionality: it needs to either always keep all
>> state serialized, or serialize it on demand. Systemd provides a
>> "file descriptor store" [2] that can be used to keep files open
>> while the process is not running. There are obviously exceptions…
>> for example graphical applications. But for many system services and
>> background user services, my expecation is that they are invisibly
>> restarted in the background without any user interaction. Each program
>> that allows this moves us one step closer towards the goal of being
>> upgrades being a non-event.
> I'd question the criteria we use for deciding when to restart services.
> Typically we only restart a daemon if the daemon binary is upgraded.
> This ignores any libraries that the daemon links to, which are just
> as important to its functionality, reliability and security as the
> executable binary.  Only restarting daemons when the executable binary
> changes gives us a false sense of having solved the upgrades problems.
> To arbitrarily pick on 'colord', there are 35 libraries it links to
> that could be considered triggers for restart on upgrade. This is
> an especially important problem for any daemons that link to TLS or
> general crypto libraries, as it means we're not actually applying
> security updates in those libraries to any running daemons that use
> them, unless you always restart the entire host OS.

This is out of the scope of this Change but I am wondering whether this
should be something RPM supports somehow. Yes, there are triggers, that
would allow for scriptlets to run if another package gets updated. But
this is super cumbersome for this use case and requires the packager to
keep track of all the dependencies (recursively!).

My first thought was a new trigger scriptlet type that would run if any
dependencies get updated. But I guess this would trigger much too often.
Dependencies from scriptlets or meta dependencies can ofc be filtered
out but this will probably still leave too many dependencies.

May be we could have some REs to filter the dependencies to look at.
Just matching *.so* may do the trick but looks pretty fragile.

Florian