all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
@ 2023-06-03 11:06 Attila Lendvai
  2023-06-05  7:08 ` Ludovic Courtès
  0 siblings, 1 reply; 7+ messages in thread
From: Attila Lendvai @ 2023-06-03 11:06 UTC (permalink / raw)
  To: 63869

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)





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-03 11:06 bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv` Attila Lendvai
@ 2023-06-05  7:08 ` Ludovic Courtès
  2023-06-06 16:41   ` Maxim Cournoyer
  0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2023-06-05  7:08 UTC (permalink / raw)
  To: Attila Lendvai; +Cc: 63869

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-05  7:08 ` Ludovic Courtès
@ 2023-06-06 16:41   ` Maxim Cournoyer
  2023-06-09 13:22     ` Ludovic Courtès
  0 siblings, 1 reply; 7+ messages in thread
From: Maxim Cournoyer @ 2023-06-06 16:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Attila Lendvai, 63869

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-06 16:41   ` Maxim Cournoyer
@ 2023-06-09 13:22     ` Ludovic Courtès
  2023-06-09 17:41       ` Maxim Cournoyer
  0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2023-06-09 13:22 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Attila Lendvai, 63869

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-09 13:22     ` Ludovic Courtès
@ 2023-06-09 17:41       ` Maxim Cournoyer
  2023-06-14 16:47         ` Ludovic Courtès
  0 siblings, 1 reply; 7+ messages in thread
From: Maxim Cournoyer @ 2023-06-09 17:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Attila Lendvai, 63869

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-09 17:41       ` Maxim Cournoyer
@ 2023-06-14 16:47         ` Ludovic Courtès
  2023-06-19  1:28           ` Maxim Cournoyer
  0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2023-06-14 16:47 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Attila Lendvai, 63869-done

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
  2023-06-14 16:47         ` Ludovic Courtès
@ 2023-06-19  1:28           ` Maxim Cournoyer
  0 siblings, 0 replies; 7+ messages in thread
From: Maxim Cournoyer @ 2023-06-19  1:28 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Attila Lendvai, 63869-done

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-06-19  1:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-03 11:06 bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv` Attila Lendvai
2023-06-05  7:08 ` Ludovic Courtès
2023-06-06 16:41   ` Maxim Cournoyer
2023-06-09 13:22     ` Ludovic Courtès
2023-06-09 17:41       ` Maxim Cournoyer
2023-06-14 16:47         ` Ludovic Courtès
2023-06-19  1:28           ` Maxim Cournoyer

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.