[zeromq-dev] [RFC] systemd socket activation for libzmq

[Luca Boccassi]

On Tue, 2016-05-31 at 11:06 -0700, Jim Garlick wrote:
> On Tue, May 31, 2016 at 05:47:24PM +0100, Luca Boccassi wrote:
> > On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote:
> > > On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote:
> > > > Hi,
> > > > 
> > > > Awesome, the fact czmq handles that is good enough for me. Closed the
> > > > request.
> > > > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
> > > > > Hi,
> > > > >
> > > > > Ale's thread about Setting privileges on a UNIX socket inspired me to
> > > > > create small patch to libzmq adding automatic systemd socket
> > > > > activation support.
> > > > > https://github.com/zeromq/libzmq/pull/2015
> > > > >
> > > > > Right now the feature is fairly minimal - limited to ipc transport -
> > > > > and tested manually using malamute broker. I would like to hear any
> > > > > feedback. If you consider it as useful (or want to avoid dependency on
> > > > > the most hated OSS software on the planet ;-)), please say so.
> > > > 
> > > > Hi,
> > > > 
> > > > That functionality is already implemented for both IPC and TCP sockets.
> > > > 
> > > > The low level library has the ZMQ_USE_FD socket option to pass a file
> > > > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
> > > > zsys_set_auto_use_fd(1) function to let zmq automatically match
> > > > endpoints to the corresponding sockets managed by systemd. As long as
> > > > the metadata matches (eg: file path for IPC, address + port for TCP), it
> > > > will just work out of the box.
> > > > 
> > > > Kind regards,
> > > > Luca Boccassi
> > > 
> > > Somehow I missed that - sounds useful!
> > > 
> > > Is the usual reconnect behavior disabled when this option is present,
> > > or is that what the aforementioned metadata is used for?  I couldn't
> > > find the answer in
> > >   http://api.zeromq.org/4-2:zmq-setsockopt
> > > 
> > > or in the note about reconnect exceptions in
> > >   http://api.zeromq.org/4-2:zmq-connect
> > > 
> > > Thanks,
> > > 
> > > Jim Garlick
> > 
> > Hi,
> > 
> > This is used only for server-ish sockets - ie, all those that do any
> > sort of bind and you would use with zmq_bind, so it does not affect
> > zmq_connect (or re-connect).
> > 
> > I thought about adding it for the connect side too, but IMHO it wouldn't
> > make much sense. The purpose of systemd-managed sockets is to let
> > servers be started only when a client attempts to connect, and to
> > disentangle dependencies between services and allow them to start in
> > parallel at boot, while having systemd manage the FD buffer so that no
> > messages are lost in either scenario.
> > Neither of these would apply for client-ish sockets.
> > 
> > But we can of course look into it, do you have a use case where it would
> > be useful to have?
> > 
> > Kind regards,
> > Luca Boccassi
> 
> Ah, thanks for the clarification.
> 
> Well, there are probably other ways to accomplish my use case.
> We have a broker that loads "plugins" as threads communicating with
> the broker over a per-plugin ZMQ_PAIR inproc:// socket.
> We'd like to be able to launch plugins as processes with fork/exec.
> What I had in mind when I heard about ZMQ_USE_FD was something like
> ZMQ_PAIR over file descriptors obtained with socketpair(), one end
> passed to plugin, one end retained by broker.
> 
> Having an endpoint that doesn't appear in any namespace simplifies
> life a bit compared to ipc:// or tcp:// - it wouldn't need to be
> protected against unauthorized access for example.
> 
> Jim

The use case sounds interesting, but as you correctly flagged it before,
the issue with the connect is that by design the actual socket might be
closed and reopened by the library, so I'm not sure how it could be made
to work.

Maybe it's time for a new intraproc:// transport, perhaps using sealed
pipes that were posted on this ML a while ago?
https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160531/37616be1/attachment.sig>