Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote:
> Dne 28. 07. 21 v 15:07 Ben Cotton napsal(a):
> == Benefit to Fedora ==
> >This fixes a long-standing missing feature. We certainly wanted to
> >have this, but the technical implementation is not trivial, because we
> >need to (safely and robustly) reach from the a privileged context into
> >unprivileged user manager instances. Such functionality has been added
> >in systemd, so finally we are able to do this in a fairly clean
> >manner.
> 
> Only partially true. There is `tracer` with dnf plugin. It have been
> here for few years. Users are suggested which services need to be
> restarted (and are safe to be restarted), if they need to
> logoff/login or even restart a machine.

Right. Those approaches are complementary really — it is better to restart
everything that can be safely restarted directly from package scriptlets,
and 'tracer' or similar approaches can be used to figure out what was missed.

> >User services are becoming more and more important. In particular, we
> >want to be able to restart services such as `pipewire.service` during
> >upgrades, without requiring a restart of the machine for the upgrade
> >to take effect. Systemd only provides the general functionality.
> >Package maintainers will need to mark their services for restart using
> >`%systemd_postun_with_restart` if appropriate.
> 
> I think that this needs to be expanded.

Thanks. I added a paragraph and reworded some stuff. Please say if
you think there should be more.

> 1) It will be good to expand what is actually an user service. I had to look it up. Hint for others:
> 
>  systemctl --user status
> 
> 2) Do you want to restart all user services? Or just these which are
> marked by maintainers to be safe to be restarted (e.g., pipewire)?

Only select ones. This is maintainer choice.

> 3) Can we have some discussions which user services are safe to
> restart and which not? E.g., the Tracer configuration is a good
> start point.

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.

As to which applications can be restarted: each case is different…
I hope that package maintainers mostly know this for their packages.
And in cases where it's not already possible, working with upstream
will be necessary.

I looked briefly into the tracer package metadata, and it seems
rather sparse… It knows about systemd, but not systemd --user, afaict.
So it may be used as a starting to point to figure out what is not
restarted, but not how to restart it.

[1] https://github.com/systemd/systemd/issues/17308
[2] https://www.freedesktop.org/software/systemd/man/sd_notify.html#FDSTORE=1

> >== How To Test ==
> >Upgrade packages with user services that should be restarted. Look at
> >logs or otherwise verify that the new version is running.
> 
> Can the guidance be more specific here?

Also updated, ptal.

> >== User Experience ==
> >Updates of user services take effect immediately (if so configured in
> >the providing packages).
> 
> Can this be expanded too? What will be the **practical** impact?
> Will my audio stops? Or has just little glitch? What about my
> bluetooth connections? Etc.

Oh, I don't know audio well enough… It'll be up to the package maintainer
to decide if the service can support this at all, and if the update
creates some user-visible interruption, if this interruption is worth it.

Zbyszek
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux