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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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