[PATCH] prepare streams based messaging

[Amitay Isaacs]

Hi Volker,

On Sat, Jun 18, 2016 at 1:29 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> On Wed, Jun 01, 2016 at 04:44:53PM +1000, Amitay Isaacs wrote:
> > I uncovered a problem while trying to run the tests fddrn/fdsrc.
> >
> > I tried to run fddrn as follows:
> >
> >     $ bin/fddrn bin/tfdd /tmp/tfd
> >     tfd_init failed: No such file or directory
> >
> > While debugging this, I figured out that the tfdd path needs to be
> absolute.
> >
> > Q: Do you need to do chdir("/") in tfd_tfdd_child()?  Can we do that in
> > tfdd binary?
>
> With the attached patch this should work fine now. Initializing the
> daemon is a pretty tricky dance, I'd appreciate review on that particular
> piece. I've added a -i (interactive, non-forking) option to tfdd for
> consumption in autobuild, which can't deal well with runaway daemons.
>
> Volker
>

It is indeed tricky.

The fcntl lock on lockfile is lost when you become daemon (rather when the
parent goes away).  I can start another instance of tfdd and it will
happily overwrite the previous lockfile and the socket.

It's also bad without becoming daemon.  I tried to start two instances in
foreground as follows:

$ bin/tfdd -i /tmp/sock &
[1] 19784
$ bin/tfdd -i /tmp/sock
[1]+  Broken pipe             bin/tfdd -i /tmp/sock

Trying to start new instance will actually kill the first instance.  And
here's the relevant strace output:

$ strace -p 19784
strace: Process 19784 attached
epoll_wait(5, [{EPOLLIN, {u32=35974128, u64=35974128}}], 1, 30000) = 1
epoll_ctl(5, EPOLL_CTL_DEL, 4, 0x7ffd4f3306e0) = 0
accept(4, {sa_family=AF_LOCAL, NULL}, [2]) = 6
epoll_ctl(5, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=35974016,
u64=35974016}}) = 0
fcntl(6, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
write(6, "\1\0\0\0\0\0\0\0", 8)         = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=19784, si_uid=1000}
---
+++ killed by SIGPIPE +++


It's rather tricky to test the existence of tfdd by trying to connect to it
since tfdd writes to the socket immediately.  We either need to ignore
signal SIGPIPE on the initial write or may be just rely on existence of
process?  Doing a connect test is much better since it also tests the
responsiveness of tfdd.  But there is no recovery mechanism in tfdd in case
it is stuck.  Considering that tfdd is "simple" process (i.e. it's
implementing a simple protocol), it might be sufficient to rely on the
existence of the process.

Amitay.