aboutsummaryrefslogtreecommitdiffstats
path: root/erts/epmd/test/epmd.spec.vxworks
diff options
context:
space:
mode:
authorAlexey Lebedeff <[email protected]>2015-12-14 15:15:52 +0300
committerAlexey Lebedeff <[email protected]>2015-12-15 12:33:35 +0300
commit8e6d005dcd8f62745d28d1820c4b2a5025634f5f (patch)
treef6be81779b7bbf365a3e69a7df3c7b7f7f9aba13 /erts/epmd/test/epmd.spec.vxworks
parenta16b7d63cc665dca90305b146c15de04487808db (diff)
downloadotp-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 'erts/epmd/test/epmd.spec.vxworks')
0 files changed, 0 insertions, 0 deletions