Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hi, > > 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 :-)). -- Thanks, Maxim
