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

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Aug 30 07:34:05 CEST 2016

On Mon 2016-08-29 06:14:57 -0400, Werner Koch wrote:
> On Fri, 12 Aug 2016 22:07, dkg at fifthhorseman.net said:
>> However we solve those problems, having process supervision and socket
>> activation still seem like good things, so i'd still like these patches
>> to be considered by upstream GnuPG.  I don't think they break any
> I will look at them in detail soon.  I would however like a more
> generalized approach using options like --listing-socket-foo and nothing
> systemd specific.

For dirmngr, which only listens on a single socket, this isn't too
troubling -- i could replace --supervised with something like
"--listen-socket-fd 3 --foreground", so the user interface for dirmngr
only gets a little bit more complicated.

But for gpg-agent, which can potentially listen on 4 different kinds of
sockets, --listen-socket-extra-fd N", etc would be a worse

The current proposed --supervised implementation uses a set of
environment variables that are provided by the supervisor under a
straightforward naming convention (LISTEN_FDS, LISTEN_PID, and
LISTEN_FDNAMES).  While systemd did establish this convention, it needs
by no means be limited to systemd, and the patches i've sent do not link
to libsystemd at all.

I'm currently working on an addition to the runit suite (to be called
listen(8)) that will allow people to trigger this convention from any OS
that supports both runit and the standard POSIX socket(7)
abstraction. [0]

In particular for gpg-agent, moving to a --listen-socket-FOO-fd N
invocation model would leave systemd users with the necessity of writing
a wrapper program that parses the LISTEN_* variables, builds a new
gpg-agent commandline, and exec()s it.

If you want to make it easy to support systemd users, this wrapper
itself should probably be shipped with gnupg, and it will be more code
to maintain than the current relatively small implementation.

I'd really prefer to have a simpler interface, with less code, that
supports the most widely-adopted existing socket-activated supervision
system that is already in use, than to have a generic implementation
with more knobs that ends up needing an additional wrapper to be useful
in the common case.



[0] http://skarnet.org/cgi-bin/archive.cgi?2:mss:1342:201608:igkfadclflfmoeckkhne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20160830/6fc970ab/attachment.sig>

More information about the Gnupg-devel mailing list