Re: [PATCH] services: lsh: Add "graceful" handling of daemonic option.

[Deck Pickard]

On 6 Dec 2014 15:28, "Ludovic Courtès" <address@hidden> wrote:
>
> Deck Pickard <address@hidden> skribis:
>
> > From 1fef935d6292016c04b9234eedb5dcaf006dc152 Mon Sep 17 00:00:00 2001
> > From: nebuli <address@hidden>
> > Date: Wed, 3 Dec 2014 22:51:48 +0100
> > Subject: [PATCH] services: lsh: Add graceful handling of daemonic option.
> >
> > * doc/guix.texi: Mention use case.
> > * gnu/services/ssh.scm (lsh-service): New #:keys (daemonic?, pid-file?,
> >   pid-file).  Build new lshd-command and expand service-requirement
> >   field.
>
> Nice!
>
> >  (define* (lsh-service #:key
> >                        (lsh lsh)
> > +                      (daemonic? #f)
> >                        (host-key "/etc/lsh/host-key")
> >                        (interfaces '())
> >                        (port-number 22)
> >                        (allow-empty-passwords? #f)
> >                        (root-login? #f)
> >                        (syslog-output? #t)
> > +                      (pid-file? #f)
> > +                      (pid-file "/var/run/lshd.pid")
> >                        (x11-forwarding? #t)
> >                        (tcp/ip-forwarding? #t)
> >                        (password-authentication? #t)
>
> I would be tempted to not expose #:daemonic?, #:pid-file? and
> #:syslog-output?, and instead always use --daemonic --pid-file=...
>
> In particular, when using --daemonic, having the PID file is required,
> otherwise dmd won’t know what the PID of this process is, and thus will
> be unable to control it.  For that reason, #:pid-file? must not be
> exposed.
>
> WDYT?

I implemented this because, from what I gather, lshd will write to syslog only in '--daemonic' mode, otherwise it spams the controlling terminal on which dmd is running. And I wanted lsh to use syslog!

As it is now, dmd captures the right PID from the "make-fork" constructor alone, while having no idea of pid files; I went as far as to write dmd service (and 'deco sideloding' it), which printed out both PIDs, they were eqv...

There might still remain a use case with daemonic? equal to false for someone out there, even for simple reason of lack of functioning syslog (as well as a use case of choosing not to log at all), shrug...  

Change default to (daemonic? #t) and adjust the docs? Your call...
I did not mention pid file related keys in the docs, because it would be only useful to someone who had to bother to look at actual lsh-service signature, like someone who did need pid file for some strange purpose...

>
> > +  (define requires
> > +    (if (and daemonic? syslog-output?)
> > +        '(networking syslogd)
> > +        '(networking)))
>
> If we agree on the above, that would become '(networking syslogd)
> unconditionally.
>

No, as I explained; one thing is having a chosen set of defaults, another removing flexibility... lsh and/or dmd behaviour could change or someone could like to rewrite lsh service definition.

> >      (return (service
> >               (documentation "GNU lsh SSH server")
> >               (provision '(ssh-daemon))
> > -             (requirement '(networking))
> > +             (requirement #~(address@hidden))
>
> This is strictly equivalent to:
>
>   (requirement `(,@requires))
>
> or simply:
>
>   (requirement requires)
>
> :-)
>
> G-expressions are only needed when capturing references to /gnu/store
> items, packages, etc.
>
> Thanks,
> Ludo’.

Roger, still groking my way around, at least it doesn't matter apart from couple useless macro expansions.
Drp,
--
(or ((,\ (x) `(,x x)) '(,\ (x) `(,x x))) (smth (that 'like)))