[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.

> Attila Lendvai <attila@lendvai.name> 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?

> Ludovic Courtès <ludo@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?).

> 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?

> Hi,

>

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>

>> Ludovic Courtès <ludo@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?

> 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.

> Ludovic Courtès <ludo@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 :-)).

> Hi Maxim & Attila,

>

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>

>> Ludovic Courtès <ludo@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.