bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi, Ludovic Courtès writes: > Hi Maxim & Attila, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: > > [...] > > When a service is stopped at the time of reconfigure, it is immediately > replaced and then started. > > Replacing works by unregistering the old instance from the registry and > registering a new one. As a side effect, you end up with an instance > that’s enabled (see ‘service-registry’ in (shepherd services)). > > I never thought it could be a problem. WDYT? I think it probably goes against users' expectation (i.e., systemd) that a disabled service stays disabled unless manually re-enabled (I think that's the way it is for systemd, even when the system is upgraded?). >>> >>> Does systemd have a notion of enabled/disabled? >> >> Yes! 'systemctl disable ' [0]. It does stick around until the >> user changes it, I can confirm the behavior which I've recently seen on >> a Debian system upgrade (the service remained disabled and the updater >> warned it wouldn't be restarted because of that). >> >> [0] >> https://www.freedesktop.org/software/systemd/man/systemctl.html#disable%20UNIT%E2%80%A6 >> >>> I’m fine either way. We can also change it such that replacing a >>> disabled service does not re-enable it; that’s probably more logical. >> >> I guess sticking to the established convention set by systemd would >> cause the least friction down the road. If we agree on this, we should >> reopen this bug (and eventually fix it :-)). > > Agreed, fixed in Shepherd commit > 52db31e5b061440cd110da4848ab230ce09f365a. Nifty! You rock! :-) -- Thanks, Maxim
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi Maxim & Attila, Maxim Cournoyer skribis: > Ludovic Courtès writes: [...] When a service is stopped at the time of reconfigure, it is immediately replaced and then started. Replacing works by unregistering the old instance from the registry and registering a new one. As a side effect, you end up with an instance that’s enabled (see ‘service-registry’ in (shepherd services)). I never thought it could be a problem. WDYT? >>> >>> I think it probably goes against users' expectation (i.e., systemd) that >>> a disabled service stays disabled unless manually re-enabled (I think >>> that's the way it is for systemd, even when the system is upgraded?). >> >> Does systemd have a notion of enabled/disabled? > > Yes! 'systemctl disable ' [0]. It does stick around until the > user changes it, I can confirm the behavior which I've recently seen on > a Debian system upgrade (the service remained disabled and the updater > warned it wouldn't be restarted because of that). > > [0] > https://www.freedesktop.org/software/systemd/man/systemctl.html#disable%20UNIT%E2%80%A6 > >> I’m fine either way. We can also change it such that replacing a >> disabled service does not re-enable it; that’s probably more logical. > > I guess sticking to the established convention set by systemd would > cause the least friction down the road. If we agree on this, we should > reopen this bug (and eventually fix it :-)). Agreed, fixed in Shepherd commit 52db31e5b061440cd110da4848ab230ce09f365a. Thanks! Ludo’.
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: > > [...] > >>> When a service is stopped at the time of reconfigure, it is immediately >>> replaced and then started. >>> >>> Replacing works by unregistering the old instance from the registry and >>> registering a new one. As a side effect, you end up with an instance >>> that’s enabled (see ‘service-registry’ in (shepherd services)). >>> >>> I never thought it could be a problem. WDYT? >> >> I think it probably goes against users' expectation (i.e., systemd) that >> a disabled service stays disabled unless manually re-enabled (I think >> that's the way it is for systemd, even when the system is upgraded?). > > Does systemd have a notion of enabled/disabled? Yes! 'systemctl disable ' [0]. It does stick around until the user changes it, I can confirm the behavior which I've recently seen on a Debian system upgrade (the service remained disabled and the updater warned it wouldn't be restarted because of that). [0] https://www.freedesktop.org/software/systemd/man/systemctl.html#disable%20UNIT%E2%80%A6 > I’m fine either way. We can also change it such that replacing a > disabled service does not re-enable it; that’s probably more logical. I guess sticking to the established convention set by systemd would cause the least friction down the road. If we agree on this, we should reopen this bug (and eventually fix it :-)). -- Thanks, Maxim
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: [...] >> When a service is stopped at the time of reconfigure, it is immediately >> replaced and then started. >> >> Replacing works by unregistering the old instance from the registry and >> registering a new one. As a side effect, you end up with an instance >> that’s enabled (see ‘service-registry’ in (shepherd services)). >> >> I never thought it could be a problem. WDYT? > > I think it probably goes against users' expectation (i.e., systemd) that > a disabled service stays disabled unless manually re-enabled (I think > that's the way it is for systemd, even when the system is upgraded?). Does systemd have a notion of enabled/disabled? > If we want Guix/Shepherd to differ from this common expectation (on the > ground that declarative should prevail over state, maybe?), it'd be good > to have at least this documented/explained somewhere. > > What do you think? I’m fine either way. We can also change it such that replacing a disabled service does not re-enable it; that’s probably more logical. Thoughts? Ludo’.
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi Ludovic, Ludovic Courtès writes: > Attila Lendvai skribis: > >> i turn off some services using `herd disable`. then i do a `guix >> system reconfigure`, and these services get enabled and started. >> >> i would expect the enabled/disabled state to be preserved across >> reconfigures. > > When a service is stopped at the time of reconfigure, it is immediately > replaced and then started. > > Replacing works by unregistering the old instance from the registry and > registering a new one. As a side effect, you end up with an instance > that’s enabled (see ‘service-registry’ in (shepherd services)). > > I never thought it could be a problem. WDYT? I think it probably goes against users' expectation (i.e., systemd) that a disabled service stays disabled unless manually re-enabled (I think that's the way it is for systemd, even when the system is upgraded?). If we want Guix/Shepherd to differ from this common expectation (on the ground that declarative should prevail over state, maybe?), it'd be good to have at least this documented/explained somewhere. What do you think? -- Thanks, Maxim
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Attila Lendvai skribis: > i turn off some services using `herd disable`. then i do a `guix system > reconfigure`, and these services get enabled and started. > > i would expect the enabled/disabled state to be preserved across reconfigures. When a service is stopped at the time of reconfigure, it is immediately replaced and then started. Replacing works by unregistering the old instance from the registry and registering a new one. As a side effect, you end up with an instance that’s enabled (see ‘service-registry’ in (shepherd services)). I never thought it could be a problem. WDYT? Ludo’.
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
i turn off some services using `herd disable`. then i do a `guix system reconfigure`, and these services get enabled and started. i would expect the enabled/disabled state to be preserved across reconfigures. if it's not easily feasible in the current architecture, then feel free to close this. it's not a crucial feature. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Those who do not weep, do not see.” — Victor Hugo (1802–1885)
