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
