[shepherd] `guix system reconfigure` forgets `herd disable mysrv`

  • Done
  • quality assurance status badge
Details
3 participants
  • Attila Lendvai
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Attila Lendvai
Severity
normal
A
A
Attila Lendvai wrote on 3 Jun 2023 13:06
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
0-BRpRybKIwoQqvJIFAqQXuRYKM-U2rlt_Gn9XVlAfxUXoNw8PHqgmoQ5qRREt_sD4UffMLKEyindAKpHdYxHb5QMq1jzybHMMq6eLnkBU4=@lendvai.name
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)
L
L
Ludovic Courtès wrote on 5 Jun 2023 09:08
(name . Attila Lendvai)(address . attila@lendvai.name)(address . 63869@debbugs.gnu.org)
87pm6ajsi9.fsf@gnu.org
Attila Lendvai <attila@lendvai.name> skribis:

Toggle quote (4 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 6 Jun 2023 18:41
(name . Ludovic Courtès)(address . ludo@gnu.org)
87jzwgczm4.fsf@gmail.com
Hi Ludovic,

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

Toggle quote (16 lines)
> 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
L
L
Ludovic Courtès wrote on 9 Jun 2023 15:22
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87fs70wz28.fsf@gnu.org
Hi,

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

Toggle quote (2 lines)
> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (13 lines)
>> 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?

Toggle quote (6 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 9 Jun 2023 19:41
(name . Ludovic Courtès)(address . ludo@gnu.org)
87a5x8bkjl.fsf@gmail.com
Hi Ludovic,

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

Toggle quote (23 lines)
> 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).


Toggle quote (3 lines)
> 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
L
L
Ludovic Courtès wrote on 14 Jun 2023 18:47
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87fs6urnwo.fsf@gnu.org
Hi Maxim & Attila,

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

Toggle quote (2 lines)
> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (29 lines)
>>>> 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’.
Closed
M
M
Maxim Cournoyer wrote on 19 Jun 2023 03:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
87a5wwtf4s.fsf@gmail.com
Hi,

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

Toggle quote (40 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 63869@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 63869
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch