Hi, Ludovic Courtès <l...@gnu.org> writes:
> Hi Maxim & Attila, > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> Ludovic Courtès <l...@gnu.org> 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 <service>' [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