Ok, I started a branch called systemd with the two files sd-daemon.c and
sd-daemon.h included.
A few things look a little strange -- systemd listen sockets are
automatically assigned as file descriptors number 3, 4, 5. I guess we'll
have to test systemd very early to make sure no other file descriptors have
been allocated.
Also, in the documentation about systemd, there was a long passage about
how the daemonizing should be done external to the program -- is that still
the recommended policy? I guess the early testing could help there.
Finally, as I understand it, systemd will present the listen socket to
owserver -- so we have to think about how command line parameters are
handled. (Or configuration files)
A typical owserver invocation:
# owserver usb bus master, Farenheit temperatures, connect to a remote
owserver as well
owserver -p 4304 -u -F -s otherhost:4304
We would ignore the "-p 4304" (actually all the "-p" parameters) but use
the other options?
The examples have only 1 LISTEN_FDS allocated, but hint that multiple could
be passed. That would be not problem for us.
On Mon, Jun 9, 2014 at 7:01 AM, Tomasz Torcz <to...@pipebreaker.pl> wrote:
> On Thu, Jun 05, 2014 at 05:34:01PM -0400, Paul Alfille wrote:
> > Tomasz,
> >
> > I'm having trouble visualizing how the systemd triggering works. When a
> > program like owread tries to contact owserver, is owserver started? Is
> this
> > done by monitoring the typical owserver port (4304)? How about other
> > owserver friends?
>
> Hi Paul,
>
> Socket activation works is basically an inetd-like functionality.
> Systemd binds to 4304 port and listens. When owread (or anything else)
> tries to connect to 4304, owserver is started (by systemd) and connection
> is
> handled to owserver.
> (in addition to TCP/UDP ports, systemd can also listen on UNIX sockets,
> FIFOs, netlink messages and few more sources; but it is not relevant to
> owfs).
>
> In Fedora, I treat owserver as a central multiplexer. Other utilities
> (owhttpd, owftpd, fuse etc.) do not control 1-wire bus directly, but
> connect to owserver. It's been working fine for few months (I did not
> receive any bugreports). For the reference, here are *.service
> definition that I use: http://pkgs.fedoraproject.org/cgit/owfs.git/tree/
> With one central multiplexer, admin has only to customize owserver.service
> file and put his adapter settings there.
>
> Socket activation would let me simplify the dependencies encoded
> in *.service files - I would be able to drop
> Requires=/After=owserver.service lines.
> It would also make possible to restart owserver without dropping
> connections from owhttpd/owftpd/fuse etc.
>
> > If you don't mind describing the process more, or giving pointers to
> > documentation, perhaps we can assist in the implementation.
> >
> > I looked at the code you referenced (iodine), but it doesn't have any
> > explanations. Is iodine an example client or the controlling code?
>
> Controlling code lies in systemd. iodine is a "client". Traditionally,
> in order to accept network connections, you have to:
> - bind() socket
> - listen() on it
> - accept() incoming connections
> Those 3 steps are delegated to systemd. When owserver is started by
> socket activation, it receives already connected file handles to sockets.
> The code in iodine represents how autodetection works: if there are
> LISTEN_PID
> and LISTEN_FDS variables in environment, that means we are started under
> systemd socket-activation.
> If the are no LISTEN_* vars, code fallbacks to manually establishing
> sockets.
>
> Longer writeups are available:
> http://0pointer.de/blog/projects/socket-activation.html
> http://0pointer.de/blog/projects/socket-activation2.html
> I've personally used iodine patch as an example when implementing socket
> activation in some small utilities.
>
> Socket activation is inspired by Darwin's launchd feature. That's why
> I've asked about launchd in context of Mac porting. I don't know launchd,
> but maybe some code can be shared?
>
>
> --
> Tomasz Torcz 72->|
> 80->|
> xmpp: zdzich...@chrome.pl 72->|
> 80->|
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://www.hpccsystems.com
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
