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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#63869: closed ([shepherd] `guix system reconfigure` forgets
 `herd disable mysrv`)
Date: Wed, 14 Jun 2023 16:49:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 14 Jun 2023 18:47:51 +0200
with message-id <87fs6urnwo.fsf <at> gnu.org>
and subject line Re: bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
has caused the debbugs.gnu.org bug report #63869,
regarding [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
63869: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63869
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 part 3 (message/rfc822, inline)]

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

Previous Next

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