bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Attila Lendvai]

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)

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Ludovic Courtès]

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?

Ludo’.

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

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

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`

[Ludovic Courtès]

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?

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

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

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

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

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Ludovic Courtès]

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.

Thanks!

Ludo’.

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Maxim Cournoyer]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

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

Nifty!  You rock! :-)

-- 
Thanks,
Maxim