[PATCH] prepare streams based messaging

Volker Lendecke vl at samba.org
Mon Jun 20 19:47:05 UTC 2016

Hi, Amitay!

On Mon, Jun 20, 2016 at 03:29:20PM +1000, Amitay Isaacs wrote:
> 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.

Thanks for pointing this out! Attached find the next round that should
fix both issues :-)

> 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?

We need to make tfdd as robust as possible, so this was a very obvious
bug, thanks for finding it!

> 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

What would be the way out if tfdd is really stuck? The lockfile is held,
the socket is bound, what shall we do? I think this is about as bad as
the file system being stuck, at least from my point of view.

My plan is also to exit all processes connected to tfdd when it dies,
at least initially. Making that recover-save would be non-trivial,
we'd have to implement something like a "grace" mode to allow everyone
to register its unique id given in the last incarnation. Or we need to
store the unique ids persistenly on disk. I'm not sure I like either of
both, at least until people force us to make it tfdd-crash safe.

New patch attached :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tfd.patch
Type: text/x-diff
Size: 42262 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160620/ee726aec/tfd.diff>

More information about the samba-technical mailing list