GNU bug report logs - #63869
[shepherd] `guix system reconfigure` forgets `herd disable mysrv`

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63869 in the body.
You can then email your comments to 63869 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Attila Lendvai <attila <at> lendvai.name>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Date: Sat, 03 Jun 2023 11:06:31 +0000

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)

Message #8 received at 63869 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Attila Lendvai <attila <at> lendvai.name>
Cc: 63869 <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Mon, 05 Jun 2023 09:08:30 +0200

Attila Lendvai <attila <at> 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’.

Message #11 received at 63869 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Attila Lendvai <attila <at> lendvai.name>, 63869 <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Tue, 06 Jun 2023 12:41:23 -0400

Hi Ludovic,

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

> Attila Lendvai <attila <at> 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

Message #14 received at 63869 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Attila Lendvai <attila <at> lendvai.name>, 63869 <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Fri, 09 Jun 2023 15:22:07 +0200

Hi,

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

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

Message #17 received at 63869 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Attila Lendvai <attila <at> lendvai.name>, 63869 <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Fri, 09 Jun 2023 13:41:18 -0400

Hi Ludovic,

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> 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

Message #22 received at 63869-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Attila Lendvai <attila <at> lendvai.name>, 63869-done <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Wed, 14 Jun 2023 18:47:51 +0200

Hi Maxim & Attila,

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

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

Message #25 received at 63869-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Attila Lendvai <attila <at> lendvai.name>, 63869-done <at> debbugs.gnu.org
Subject: Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd
 disable mysrv`
Date: Sun, 18 Jun 2023 21:28:03 -0400

Hi,

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

> Hi Maxim & Attila,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.