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 _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
