guix home reconfigure does not apply changes to shepherd services

Open

Details

2 participants

Andrew Tropin
Oleg Pykhalov

Owner: unassigned

Submitted by: Oleg Pykhalov

Severity: normal

Oleg Pykhalov wrote on 12 Oct 2021 00:53

Recipients:(name . bug-guix)(address . bug-guix@gnu.org)(name . Andrew Tropin)(address . andrew@trop.in)

Message-ID:87k0ijxjfu.fsf@gmail.com

After changing a home shepherd service I tried to reconfigure with 'guix

home reconfigure'.

Process started by a service did not restart. Assuming home shepherd is

like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the

process restarted but without changes in a service definition.

To forcely apply the changes I invoked 'herd stop root' and then ran

'guix home reconfigure' again which spawned new shepherd with applied

changes.

Oleg.

Andrew Tropin wrote on 15 Oct 2021 08:21

Recipients:

Message-ID:878ryuoljj.fsf@trop.in

On 2021-10-12 01:53, Oleg Pykhalov wrote:

Toggle quote (7 lines)

> After changing a home shepherd service I tried to reconfigure with 'guix

> home reconfigure'.

> Process started by a service did not restart. Assuming home shepherd is

> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the

> process restarted but without changes in a service definition.

It's intentional, only `herd load root new-config.conf` called on

activation, so existing services are not affected to prevent situations,

where emacs daemon or other important process killed in the middle of

unsaved work.

You can do `herd unload root SERVICE_NAME` and after that reconfigure

will apply the latest configuration and start the service (if

auto-start? is true).

Toggle quote (7 lines)

> To forcely apply the changes I invoked 'herd stop root' and then ran

> 'guix home reconfigure' again which spawned new shepherd with applied

> changes.

> Oleg.

-- 
Best regards,
Andrew Tropin

Oleg Pykhalov wrote on 16 Oct 2021 17:06

Re: bug#51141: guix home reconfigure does not apply changes to shepherd services

Recipients:(name . Andrew Tropin)(address . andrew@trop.in)(address . 51141@debbugs.gnu.org)

Message-ID:87fst180wp.fsf@gmail.com

Hi Andrew,

Andrew Tropin <andrew@trop.in> writes:

Toggle quote (14 lines)> On 2021-10-12 01:53, Oleg Pykhalov wrote:
>
>> After changing a home shepherd service I tried to reconfigure with 'guix
>> home reconfigure'.
>>
>> Process started by a service did not restart.  Assuming home shepherd is
>> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the
>> process restarted but without changes in a service definition.
>
> It's intentional, only `herd load root new-config.conf` called on
> activation, so existing services are not affected to prevent situations,
> where emacs daemon or other important process killed in the middle of
> unsaved work.

If I change something inside a system service definition

SERVICE-shepherd-service and then invoke 'guix system reconfigure', the

service will not restart and not produce any effect until I inoke 'sudo

herd restart SERVICE'.

After herd restart the service will be running with applied changes and

does not require 'herd unload root SERVICE_NAME'.

E.g. nginx-service-type.

I think this behaviour should be the same for home services. WDYT?

Andrew Tropin wrote on 18 Oct 2021 12:04

Recipients:(name . Oleg Pykhalov)(address . go.wigust@gmail.com)(address . 51141@debbugs.gnu.org)

Message-ID:8735oyhcnr.fsf@trop.in

On 2021-10-16 18:06, Oleg Pykhalov wrote:

Toggle quote (29 lines)> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> writes:
>
>> On 2021-10-12 01:53, Oleg Pykhalov wrote:
>>
>>> After changing a home shepherd service I tried to reconfigure with 'guix
>>> home reconfigure'.
>>>
>>> Process started by a service did not restart.  Assuming home shepherd is
>>> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the
>>> process restarted but without changes in a service definition.
>>
>> It's intentional, only `herd load root new-config.conf` called on
>> activation, so existing services are not affected to prevent situations,
>> where emacs daemon or other important process killed in the middle of
>> unsaved work.
>
> If I change something inside a system service definition
> SERVICE-shepherd-service and then invoke 'guix system reconfigure', the
> service will not restart and not produce any effect until I invoke 'sudo
> herd restart SERVICE'.
>
> After herd restart the service will be running with applied changes and
> does not require 'herd unload root SERVICE_NAME'.
> E.g. nginx-service-type.
>
> I think this behaviour should be the same for home services.  WDYT?

Yes, make sense.

According to what I see in the shepherd tests:

https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61

and how it's implemented in home-shepherd:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59

It should work as you expect it.

Tried to do the following: I updated documentation field for a shepherd

service, reconfigured and it got loaded after I restarted a service.

Toggle snippet (9 lines)

~ $ herd doc state

Init, update and maybe destroy state.

~ $ herd restart state

Service state has been stopped.

Service state has been started.

~ $ herd doc state

Really init, update and maybe destroy state.

Didn't check if start action gexp is updated too, but I expect it was.

Best regards,

Andrew Tropin

Oleg Pykhalov wrote on 22 Oct 2021 01:32

Recipients:(name . Andrew Tropin)(address . andrew@trop.in)(address . 51141@debbugs.gnu.org)

Message-ID:878rymt0m4.fsf@gmail.com

Andrew Tropin <andrew@trop.in> writes:

[…]

Toggle quote (8 lines)

> According to what I see in the shepherd tests:

> https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61

> and how it's implemented in home-shepherd:

> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59

> It should work as you expect it.

It doesn't.

Toggle quote (13 lines)> Tried to do the following: I updated documentation field for a shepherd
> service, reconfigured and it got loaded after I restarted a service.
>
> ~ $ herd doc state
> Init, update and maybe destroy state.
> ~ $ herd restart state
> Service state has been stopped.
> Service state has been started.
> ~ $ herd doc state
> Really init, update and maybe destroy state.
>
> Didn't check if start action gexp is updated too, but I expect it was.

The start action is the interest, or configuration record, or service

extension.

(guix scripts system reconfigure) has a upgrade-shepherd-services

procedure, which was created in 240b57f0ca576708ebf6cfa0dfe2803fa9ff2323

and discussed in https://issues.guix.gnu.org/22039

[ The following text only describes how to reproduce the issue. ]

When I tried to write goimapnotify service no changes applied after

modifications in home-goimapnotify-shepherd-service [1] and [2], which

are typical service-type and record. I didn't have similar issues with

self-written system services.

[1]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/mail.scm#L28-45

[2]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L40-65

Service extension also requires to unload service, e.g. mcron service

extension in [1] and [2].

[1]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/package-management.scm#L16-50

[2]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L154-161

If I remove the guix-delete-generations service from home configuration,

mcron job still exists according to 'herd schedule mcron'.

Toggle snippet (6 lines)

(home-environment

(services

(list (service guix-delete-generations-service-type ;; ...

))))

Oleg.

Andrew Tropin wrote on 23 Oct 2021 09:11

Recipients:(name . Oleg Pykhalov)(address . go.wigust@gmail.com)(address . 51141@debbugs.gnu.org)

Message-ID:87bl3gkyg7.fsf@trop.in

On 2021-10-22 02:32, Oleg Pykhalov wrote:

Toggle quote (30 lines)> Andrew Tropin <andrew@trop.in> writes:
>
> […]
>
>> According to what I see in the shepherd tests:
>> https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61
>>
>> and how it's implemented in home-shepherd:
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59
>>
>> It should work as you expect it.
>
> It doesn't.
>
>> Tried to do the following: I updated documentation field for a shepherd
>> service, reconfigured and it got loaded after I restarted a service.
>>
>> ~ $ herd doc state
>> Init, update and maybe destroy state.
>> ~ $ herd restart state
>> Service state has been stopped.
>> Service state has been started.
>> ~ $ herd doc state
>> Really init, update and maybe destroy state.
>>
>> Didn't check if start action gexp is updated too, but I expect it was.
>
> The start action is the interest, or configuration record, or service
> extension.

From the experiment above it's clear that new configuration got loaded

and service record get updated after restart (at least one field of it).

Toggle quote (5 lines)

> (guix scripts system reconfigure) has a upgrade-shepherd-services

> procedure, which was created in 240b57f0ca576708ebf6cfa0dfe2803fa9ff2323

> and discussed in https://issues.guix.gnu.org/22039

The difference with update-shepherd-services is the usage of Shepherd
CLI in home service instead of Shepherd API in system service.  So the
problem can hide somewhere around this part.

Automatic unloading in home-service doesn't happens and as I said it's
by design to prevent cases of losing unsaved work.  However, it can be
implemented with an optional separate flag to shepherd configuration
record and extension to run-on-change-service or as it done in system
shepherd with the list of services, which doesn't have to be unloaded
automatically.

Toggle quote (14 lines)>
>
> [ The following text only describes how to reproduce the issue. ]
>
>
> When I tried to write goimapnotify service no changes applied after
> modifications in home-goimapnotify-shepherd-service [1] and [2], which
> are typical service-type and record.  I didn't have similar issues with
> self-written system services.
>
> [1]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/mail.scm#L28-45
> [2]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L40-65
>

I'm out of office for next 1.5 week, will check it when I come back.

Toggle quote (18 lines)>
> Service extension also requires to unload service, e.g. mcron service
> extension in [1] and [2].
>
> [1]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/package-management.scm#L16-50
> [2]: https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L154-161
>
> If I remove the guix-delete-generations service from home configuration,
> mcron job still exists according to 'herd schedule mcron'.
> --8<---------------cut here---------------start------------->8---
> (home-environment
>  (services
>   (list (service guix-delete-generations-service-type ;; ...
>                  ))))
> --8<---------------cut here---------------end--------------->8---
>
> Oleg.

BTW, please remove unreviewed changes to interpose function, they are

incorrect.

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?id=41492639e0223dc8fc1a357e1f9537577c055db7#n362

The explanation: https://issues.guix.gnu.org/50967#66

The correct version: https://git.sr.ht/~abcdw/rde/commit/4961f47c3f97c21799a39b3e906fa99b2625f331

Best regards,

Andrew Tropin

Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it

mumi current 51141

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date