Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
Dne 29. 07. 21 v 11:37 Zbigniew Jędrzejewski-Szmek napsal(a): Thanks. I added a paragraph and reworded some stuff. Please say if you think there should be more. ad Detailed Description - are the user services documented somewhere in upstream? I found just various blogposts describing this. Link to upstream documentation would be nice. ad Scope This: * Switch from |%systemd_user_postun| to |%systemd_user_postun_with_restart| if appropriate. * Make sure that their user services behave properly during restart. is still vague. Especially the part "if appropriate". I suggest to write it like: """ When the service is safe to restart - e.g., app-sealertauto@autostart.service or evolution-addressbook-factory.service then package maintainer are suggests to switch from |%systemd_user_postun| to |%systemd_user_postun_with_restart| |When the service CANNOT be safely restarted - e.g. restarting of plasma-ksmserver.service results in log off - then FIXME do nothing, or what?| |When you are in doubt and your service may or may not not result in bad user experience then FIXME (what than?).| |ad How to Test| Look at logs or otherwise verify that the script was restarted, and for an update, that the new version is running. This can be tricky and the log is quite verbose. I suggests to run $ systemctl --user status pipewire.service ● pipewire.service - Multimedia Service Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-07-30 12:43:34 CEST; 3s ago ... And check whether the time is later then the time when the rpm transaction started. Miroslav || ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
Dne 29. 07. 21 v 14:51 Joe Orton napsal(a):
1) Users asked to be able to turn this off ("why did running dnf break
my web server" etc), which I think is reasonable, we added a crude
mechanism (touch /etc/sysconfig/thing) to disable it.
I like this one.
Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
Dne 29. 07. 21 v 11:51 Daniel P. Berrangé napsal(a): 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 exactly what python3-tracer does. It transitively check all libraries the binary is using. http://tracer-package.com/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Thu, Jul 29, 2021 at 01:51:46PM +0100, Joe Orton wrote:
> On Wed, Jul 28, 2021 at 09:07:58AM -0400, Ben Cotton wrote:
> > Note from the change owner: I'm submitting this as very-very-late
> > change for F35. The implementation in systemd is mostly done, so it'll
> > become available in rawhide pretty soon. To actually make use of the
> > new functionality, individual packages should be changed to use
> > _with_restart in their scriptlets and rebuilt. This will happen over
> > time, and it's fine if each package does that on its own schedule. We
> > still do not have that many user services, and restarting from
> > packaging scriptlets will be possible and appropriate only for some of
> > them. I think it's important to make the functionality available,
> > without trying to use it everywhere immediately.
> >
> > https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade
>
> We've been restarting httpd on upgrades in %posttrans for a while, so
> it's good to see a more general version of this available. A couple of
> notes:
>
> 1) Users asked to be able to turn this off ("why did running dnf break
> my web server" etc), which I think is reasonable, we added a crude
> mechanism (touch /etc/sysconfig/thing) to disable it.
>
> 2) Blocking the dnf transaction from completing before the service
> restarts turned out to be quite painful UX and we now only run
> try-restart with --no-block. Depending on the service or service
> configuration there it can be a significant delay. Obviously a trade-off
> here since it can hide the failure case.
httpd is special because the restart is slow… but this should be an
exception I think. 'systemctl --user daemon-reexec' takes 0.260 on my laptop,
and the restart of user services would be fairly quick too.
The new macros are blocking (like the previous macros for system services),
though the timeout is limited to 15 s to prevent blocking of the upgrade
by unprivileged code. I expect the typical restart to be <<1s, so this should
be more than enough. Synchronous restart is nice when the update is part of
some script: 'sudo dnf install … && call-some-command-that-uses-the-new-api'.
This also includes stuff called internally as part of the dnf transaction
from the scriptlets: sometimes the dependent packages will require the
new functionality. That said, individual packages can use a different
form of scriptlets to make the restart asynchronous (or skip it entirely),
as appropriate.
I think that restart of most applications should be invisible or at
most cause a transient glitch, e.g. loss of audio while some
application is being restarted. I think this would be an acceptable
trade-off, better than asking users to deal with the issue. But each
app is different: httpd vs. pipewire vs. firefox vs. tracker-miner-fs-3.service…
I'm sure that different solution will need to be used.
> I tried to trace through the systemd macros (the links from the Change
> wiki under "Macro details" are broken) and it looks like you do block on
> restart/reload, is that worth reconsidering? Maybe we could wrap the
> systemd macros to achieve (1) as well for httpd, but I'd say that it
> might be a more generally useful feature too to allow users control over
> this feature.
I don't see this, the links work for me. I updated the formatting a bit.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 09:07:58AM -0400, Ben Cotton wrote:
> Note from the change owner: I'm submitting this as very-very-late
> change for F35. The implementation in systemd is mostly done, so it'll
> become available in rawhide pretty soon. To actually make use of the
> new functionality, individual packages should be changed to use
> _with_restart in their scriptlets and rebuilt. This will happen over
> time, and it's fine if each package does that on its own schedule. We
> still do not have that many user services, and restarting from
> packaging scriptlets will be possible and appropriate only for some of
> them. I think it's important to make the functionality available,
> without trying to use it everywhere immediately.
>
> https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade
We've been restarting httpd on upgrades in %posttrans for a while, so
it's good to see a more general version of this available. A couple of
notes:
1) Users asked to be able to turn this off ("why did running dnf break
my web server" etc), which I think is reasonable, we added a crude
mechanism (touch /etc/sysconfig/thing) to disable it.
2) Blocking the dnf transaction from completing before the service
restarts turned out to be quite painful UX and we now only run
try-restart with --no-block. Depending on the service or service
configuration there it can be a significant delay. Obviously a trade-off
here since it can hide the failure case.
I tried to trace through the systemd macros (the links from the Change
wiki under "Macro details" are broken) and it looks like you do block on
restart/reload, is that worth reconsidering? Maybe we could wrap the
systemd macros to achieve (1) as well for httpd, but I'd say that it
might be a more generally useful feature too to allow users control over
this feature.
Regards, Joe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On 7/29/21 11:51 AM, Daniel P. Berrangé wrote: > On Thu, Jul 29, 2021 at 09:37:53AM +, 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Thu, Jul 29, 2021 at 09:37:53AM +, 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. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 05:35:08PM +, Gary Buhrmaster wrote: > On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel > wrote: > > > > On 28/07/2021 15:07, Ben Cotton wrote: > > > Updates of user services take effect immediately (if so configured in > > > the providing packages). > > > > Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will > > cause a DE crash with termination of all running desktop applications > > (including terminal with DNF). > > As I understand it, this is a opt-in proposal, > and if a package does not choose to opt-in, > nothing changes (for them). > > And I would certainly expect that those > plasma services will choose not to opt-in > by add a _with_restart to their scriptlets. Yes, exactly. It's the same as for *system* services: some are restarted, some not, per maintainer choice. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel wrote: > > On 28/07/2021 15:07, Ben Cotton wrote: > > Updates of user services take effect immediately (if so configured in > > the providing packages). > > Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will > cause a DE crash with termination of all running desktop applications > (including terminal with DNF). As I understand it, this is a opt-in proposal, and if a package does not choose to opt-in, nothing changes (for them). And I would certainly expect that those plasma services will choose not to opt-in by add a _with_restart to their scriptlets. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On 28/07/2021 15:07, Ben Cotton wrote: Updates of user services take effect immediately (if so configured in the providing packages). Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will cause a DE crash with termination of all running desktop applications (including terminal with DNF). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
Dne 28. 07. 21 v 15:07 Ben Cotton napsal(a): Note from the change owner: I'm submitting this as very-very-late change for F35. The implementation in systemd is mostly done, so it'll become available in rawhide pretty soon. To actually make use of the new functionality, individual packages should be changed to use _with_restart in their scriptlets and rebuilt. This will happen over time, and it's fine if each package does that on its own schedule. We still do not have that many user services, and restarting from packaging scriptlets will be possible and appropriate only for some of them. I think it's important to make the functionality available, without trying to use it everywhere immediately. What will happen with services defined by user in |$HOME/.config/systemd/user ? | |Miroslav | ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
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. 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. 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)? Because systemctl --user restart plasma-ksmserver.service is not what I want to see to happen in rpm transaction as that immediately kills my session and interrupt the rpm transaction. 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. == 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? == 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. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 9:07 AM Ben Cotton wrote: > > Note from the change owner: I'm submitting this as very-very-late > change for F35. The implementation in systemd is mostly done, so it'll > become available in rawhide pretty soon. To actually make use of the > new functionality, individual packages should be changed to use > _with_restart in their scriptlets and rebuilt. This will happen over > time, and it's fine if each package does that on its own schedule. We > still do not have that many user services, and restarting from > packaging scriptlets will be possible and appropriate only for some of > them. I think it's important to make the functionality available, > without trying to use it everywhere immediately. > For what it's worth, I would argue this is actually a self-contained change since it it doesn't modify any default behavior. This would make it very late instead of very-very-late. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
