[PATCH] dirmngr: implement --supervised command (for systemd, etc)

[Justus Winter]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> * dirmngr/dirmngr.c (main): add new --supervised command, which is
>   a mode designed for running under a process supervision system
>   like systemd or runit.
> * doc/dirmngr.text: document --supervised and its interaction with

s/text/texi/

>   --log-file

Commit log style nitpick:  We like to start with a capital letter after
the colon, and end with a full stop.  Likewise for the patch subject.

I agree with this change.  If I were to implement starting gpg-agent on
demand on the Hurd using translator records (think generalized decentral
socket activation from the nineties, everything old is new again), I'd
also need such an interface.

> * dirmngr/systemd-user/{README,dirmngr.{socket,service}}: new. System
>   integration notes and configuration for socket-activated dirmngr on
>   machines that run systemd

I guess it makes sense to ship these as well.  You need to add them to
EXTRA_DIST, or they won't be included in releases.

Having said that, I believe none of us runs systemd, so we will have to
rely on contributors to keep these up-to-date.  That likely means you ;)

> "dirmngr --supervised" is a way to invoke dirmngr such that a system
> supervisor like systemd can provide socket-activated startup, log
> management, and scheduled shutdown.
>
> When running in this mode, dirmngr:
>
>  * does not open its own listening socket; rather, it expects to be
>    given a listening socket on file descriptor 3

Is that file descriptor fixed?  I remember systemd storing it in some
environment variable.

~~~

Do we have a policy how we deal with systemd?

I just noticed yesterday, on Debian sid, procps=2:3.3.12-2:

# ldd /bin/ps
        linux-vdso.so.1 (0x00007fffe57f1000)
        libprocps.so.6 => /lib/x86_64-linux-gnu/libprocps.so.6 (0x00007fdf59d69000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdf59b65000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdf597c3000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fdf5973b000)
        /lib64/ld-linux-x86-64.so.2 (0x000055fed7763000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fdf59514000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdf5930b000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fdf590e8000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fdf58dd9000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdf58bbb000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fdf58949000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fdf58734000)

Wow, gpg-error and gcrypt crept into /bin/ps, likely courtesy of
libsystemd.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160810/c3402c96/attachment.sig>