One-shot Shepherd services

One-shot Shepherd services

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hello Guix!

Today I added support for “one-shot” services in the Shepherd:

  https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804

One-shot services start, perform a short action, and are immediately
marked as “stopped.”  (systemd has something similar:
<https://www.freedesktop.org/software/systemd/man/systemd.service.html>.)

The use case is initialization or cleanup actions like the ‘user-homes’
service.  So far ‘user-homes’ is a regular service whose ‘start’ method
always fails; as a result, we always see this message:

  Service user-homes could not be started.

From there on, we’ll be able to mark this service as one-shot (patch
below), and thus shepherd will notice that it successfully started (or
not) and yet mark it as stopped, which was always the intent.

There are other cases where this could be useful.  For instance, we
could turn service activation snippets into one-shot services.

Since this augments the Shepherd API, I plan to release it as 0.6.0
in time for Guix 1.0.  It contains other rather minor changes compared
to 0.5.0.

Feedback welcome!

Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 4077 bytes --]

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 3a250eeaa8..6b26da7316 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -45,6 +45,7 @@
   #:use-module (guix packages)
   #:use-module (guix utils)
   #:use-module (guix download)
+  #:use-module ((guix gexp) #:select (local-file))
   #:use-module (guix git-download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system emacs)
@@ -192,6 +193,7 @@ and provides a \"top-like\" mode (monitoring).")
     (build-system gnu-build-system)
     (arguments
      '(#:configure-flags '("--localstatedir=/var")))
+    (replacement shepherd-next)
     (native-inputs
      `(("pkg-config" ,pkg-config)
 
@@ -214,6 +216,12 @@ interface and is based on GNU Guile.")
     (home-page "https://www.gnu.org/software/shepherd/")
     (properties '((ftp-server . "alpha.gnu.org")))))
 
+(define-public shepherd-next
+  (package
+    (inherit shepherd)
+    (version "0.5.1")
+    (source (local-file "/data/src/shepherd/shepherd-0.6.0-pre1.tar.gz"))))
+
 (define-public daemontools
   (package
     (name "daemontools")
diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 12d649f542..cf7e64a783 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015, 2016, 2018 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2013, 2014, 2015, 2016, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2017 Clément Lassieur <clement@lassieur.org>
 ;;; Copyright © 2018 Carlo Zancanaro <carlo@zancanaro.id.au>
 ;;;
@@ -44,6 +44,7 @@
             shepherd-service-provision
             shepherd-service-canonical-name
             shepherd-service-requirement
+            shepherd-service-one-shot?
             shepherd-service-respawn?
             shepherd-service-start
             shepherd-service-stop
@@ -149,6 +150,8 @@ DEFAULT is given, use it as the service's default value."
   (provision     shepherd-service-provision)           ;list of symbols
   (requirement   shepherd-service-requirement          ;list of symbols
                  (default '()))
+  (one-shot?     shepherd-service-one-shot?            ;Boolean
+                 (default #f))
   (respawn?      shepherd-service-respawn?             ;Boolean
                  (default #t))
   (start         shepherd-service-start)               ;g-expression (procedure)
@@ -238,6 +241,7 @@ stored."
                        #:docstring '#$(shepherd-service-documentation service)
                        #:provides '#$(shepherd-service-provision service)
                        #:requires '#$(shepherd-service-requirement service)
+                       #:one-shot? '#$(shepherd-service-one-shot? service)
                        #:respawn? '#$(shepherd-service-respawn? service)
                        #:start #$(shepherd-service-start service)
                        #:stop #$(shepherd-service-stop service)
diff --git a/gnu/system/shadow.scm b/gnu/system/shadow.scm
index 7dc36f4a45..13b8b14095 100644
--- a/gnu/system/shadow.scm
+++ b/gnu/system/shadow.scm
@@ -323,6 +323,7 @@ accounts among ACCOUNTS+GROUPS."
   (list (shepherd-service
          (requirement '(file-systems))
          (provision '(user-homes))
+         (one-shot? #t)
          (modules '((gnu build activation)
                     (gnu system accounts)))
          (start (with-imported-modules (source-module-closure
@@ -332,9 +333,7 @@ accounts among ACCOUNTS+GROUPS."
                       (activate-user-home
                        (map sexp->user-account
                             (list #$@(map user-account->gexp accounts))))
-                      #f)))                       ;stop
-         (stop #~(const #f))
-         (respawn? #f)
+                      #t)))                       ;success
          (documentation "Create user home directories."))))
 
 (define (shells-file shells)

Re: One-shot Shepherd services

[znavko]

Is there possibility to define dependencies? F.e. networking will depend on my on-eshot service?
Also what is service 'networking' really is, and can I use wpa-supplicant + dhcp-client without meta-service networking?

April 18, 2019 9:39 PM, "Ludovic Courtès" <ludo@gnu.org> wrote:

> Hello Guix!
> 
> Today I added support for “one-shot” services in the Shepherd:
> 
> https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
> 
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.” (systemd has something similar:
> <https://www.freedesktop.org/software/systemd/man/systemd.service.html>.)
> 
> The use case is initialization or cleanup actions like the ‘user-homes’
> service. So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
> 
> Service user-homes could not be started.
> 
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
> 
> There are other cases where this could be useful. For instance, we
> could turn service activation snippets into one-shot services.
> 
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0. It contains other rather minor changes compared
> to 0.5.0.
> 
> Feedback welcome!
> 
> Ludo’.

Re: One-shot Shepherd services

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Fantastic!

This was one of the missing features for user services (e.g. a
"sync-my-data" service that users would invoke manually).

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: One-shot Shepherd services

[Ludovic Courtès]

znavko@disroot.org skribis:

> Is there possibility to define dependencies? F.e. networking will depend on my on-eshot service?

Yes, this remains unchanged.

> Also what is service 'networking' really is, and can I use wpa-supplicant + dhcp-client without meta-service networking?

On Guix System, there are several options to get the ‘networking’
service: NetworkManager, Connman, the DHCP client,
‘static-networking-service’, and a couple of others.  You have to pick
one from those.

Ludo’.

Re: User Services

[Joshua Branson]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Fantastic!
>
> This was one of the missing features for user services (e.g. a
> "sync-my-data" service that users would invoke manually).

Can you describe user services a little more for me?  It would be nice
to have the shepherd auto start my emacs...  Then I could connect via
emacsclient.  What's the status on that?

For now do I just need to run another instance of the shepherd as myself
when I login?

--
Joshua Branson
Sent from Emacs and Gnus

Re: User Services

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Joshua Branson <jbranso@dismail.de> writes:

> Can you describe user services a little more for me?  It would be nice
> to have the shepherd auto start my emacs...  Then I could connect via
> emacsclient.  What's the status on that?

Some patches have been sent, but there is quite some work to be done,
especially regarding the initial specifications.

https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html

> For now do I just need to run another instance of the shepherd as myself
> when I login?

Yes, you can do that.
I think the above link hints at some examples.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: One-shot Shepherd services

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

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

> Today I added support for “one-shot” services in the Shepherd:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
>
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.”  (systemd has something similar:
> <https://www.freedesktop.org/software/systemd/man/systemd.service.html>.)
>
> The use case is initialization or cleanup actions like the ‘user-homes’
> service.  So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
>
>   Service user-homes could not be started.
>
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
>
> There are other cases where this could be useful.  For instance, we
> could turn service activation snippets into one-shot services.
>
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0.  It contains other rather minor changes compared
> to 0.5.0.

This seems like a good change.

At first I was a little confused about why we would ever want to use a
one-shot shepherd service instead of an activation snippet, but after
reviewing the account-shepherd-service, I think I understand.  It seems
that we make it a one-shot shepherd service instead of an activation
snippet so that we can take advantage of shepherd's service dependency
management.  In the case of account-shepherd-service, it looks like we
made it a shepherd service to ensure that it would run after
'file-systems' is up.  This makes sense, since it could be a little
awkward to try to ensure proper execution order by extending the
activation service, and even if we did that, it would duplicate the
dependency management logic that shepherd gives us already.

So yeah, it makes sense to me.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: One-shot Shepherd services

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> At first I was a little confused about why we would ever want to use a
> one-shot shepherd service instead of an activation snippet, but after
> reviewing the account-shepherd-service, I think I understand.  It seems
> that we make it a one-shot shepherd service instead of an activation
> snippet so that we can take advantage of shepherd's service dependency
> management.  In the case of account-shepherd-service, it looks like we
> made it a shepherd service to ensure that it would run after
> 'file-systems' is up.  This makes sense, since it could be a little
> awkward to try to ensure proper execution order by extending the
> activation service, and even if we did that, it would duplicate the
> dependency management logic that shepherd gives us already.

Yes, that’s exactly the reason.

The ‘user-homes’ service was introduced to fix a bug whereby, if you
were using a separate /home, home directories would be created at the
wrong time—i.e., before the real /home was mounted.

Ludo’.

Re: One-shot Shepherd services

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. ápr. 30., K, 16:24):

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
> > At first I was a little confused about why we would ever want to use a
> > one-shot shepherd service instead of an activation snippet, but after
> > reviewing the account-shepherd-service, I think I understand.  It seems
> > that we make it a one-shot shepherd service instead of an activation
> > snippet so that we can take advantage of shepherd's service dependency
> > management.  In the case of account-shepherd-service, it looks like we
> > made it a shepherd service to ensure that it would run after
> > 'file-systems' is up.  This makes sense, since it could be a little
> > awkward to try to ensure proper execution order by extending the
> > activation service, and even if we did that, it would duplicate the
> > dependency management logic that shepherd gives us already.
>
> Yes, that’s exactly the reason.
>
>
This raises the question, if we are willing to convert some more activation
snippets to one-shot services. Are there any candidates for that?


> The ‘user-homes’ service was introduced to fix a bug whereby, if you
> were using a separate /home, home directories would be created at the
> wrong time—i.e., before the real /home was mounted.
>
> Ludo’.
>
>
Best regards,
g_bor

[-- Attachment #2: Type: text/html, Size: 2054 bytes --]

Re: One-shot Shepherd services

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. ápr. 30., K, 16:24):
>
>> Chris Marusich <cmmarusich@gmail.com> skribis:
>>
>> > At first I was a little confused about why we would ever want to use a
>> > one-shot shepherd service instead of an activation snippet, but after
>> > reviewing the account-shepherd-service, I think I understand.  It seems
>> > that we make it a one-shot shepherd service instead of an activation
>> > snippet so that we can take advantage of shepherd's service dependency
>> > management.  In the case of account-shepherd-service, it looks like we
>> > made it a shepherd service to ensure that it would run after
>> > 'file-systems' is up.  This makes sense, since it could be a little
>> > awkward to try to ensure proper execution order by extending the
>> > activation service, and even if we did that, it would duplicate the
>> > dependency management logic that shepherd gives us already.
>>
>> Yes, that’s exactly the reason.
>>
>>
> This raises the question, if we are willing to convert some more activation
> snippets to one-shot services. Are there any candidates for that?

Good question, maybe things like ssh-keygen.  Or maybe we could turn all
the service activation snippets into one-shot services that the service
depends on.

However, since the Shepherd 0.6.0 UI doesn’t allow users to distinguish
between one-shot and normal services, it’s probably a good idea to not
do this yet.  Otherwise “herd status” would list loads of stopped
services, which could be confusing.

I think we should first adjust the Shepherd UI.

Ludo’.

Re: One-shot Shepherd services

[Thompson, David]

On Thu, Apr 18, 2019 at 5:38 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello Guix!
>
> Today I added support for “one-shot” services in the Shepherd:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
>
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.”  (systemd has something similar:
> <https://www.freedesktop.org/software/systemd/man/systemd.service.html>.)
>
> The use case is initialization or cleanup actions like the ‘user-homes’
> service.  So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
>
>   Service user-homes could not be started.
>
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
>
> There are other cases where this could be useful.  For instance, we
> could turn service activation snippets into one-shot services.
>
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0.  It contains other rather minor changes compared
> to 0.5.0.
>
> Feedback welcome!

A big +1 from me. I use one-shot systemd services all the time.

- Dave

Re: One-shot Shepherd services

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

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

> However, since the Shepherd 0.6.0 UI doesn’t allow users to distinguish
> between one-shot and normal services, it’s probably a good idea to not
> do this yet.  Otherwise “herd status” would list loads of stopped
> services, which could be confusing.
>
> I think we should first adjust the Shepherd UI.

That makes sense.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]