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

Jim Garlick garlick at llnl.gov
Tue May 31 20:06:19 CEST 2016


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



More information about the zeromq-dev mailing list