diff options
author | Alexey Lebedeff <[email protected]> | 2015-12-14 15:15:52 +0300 |
---|---|---|
committer | Alexey Lebedeff <[email protected]> | 2015-12-15 12:33:35 +0300 |
commit | 8e6d005dcd8f62745d28d1820c4b2a5025634f5f (patch) | |
tree | f6be81779b7bbf365a3e69a7df3c7b7f7f9aba13 /lib/diameter/vsn.mk | |
parent | a16b7d63cc665dca90305b146c15de04487808db (diff) | |
download | otp-8e6d005dcd8f62745d28d1820c4b2a5025634f5f.tar.gz otp-8e6d005dcd8f62745d28d1820c4b2a5025634f5f.tar.bz2 otp-8e6d005dcd8f62745d28d1820c4b2a5025634f5f.zip |
Prevent down nodes going undetected in epmd
In the following (rare) case down node will be always registered in epmd:
- client connects to epmd and sends ALIVE2 request
- epmd reads this request and starts to process it
- during that time client socket closes in such way that subsequent
write(2) in epmd will result in error
- at this point we have node that was registered in database, but as
the connection struct has no 'keep' flag set, the do_read() closes
connection and removes it from select fdset - and so there is no way
for this node to be cleaned up later.
We've seen several epmd instances in such state on our production
systems. And while I'm not sure what was the exact sequence of events
that leads to failed write(2), issue could be easily reproduced using
SO_LINGER option for socket.
Diffstat (limited to 'lib/diameter/vsn.mk')
0 files changed, 0 insertions, 0 deletions