mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-09-05 04:27:55 +00:00
Daniel Hilst
eaedb542e1
The respawn forks from the main service loop, much further down the program than the fork at startup, so it inherits everything the parent has opened in between. That is the rescanplugins socketpair from further up this file -- the channel a subcommand process uses to hand a reloaded cmd_handlers hash back to the parent. The child closes the SSL listener and the UDP control socket but not those two, so a respawned monitor holds both ends of a channel it never reads or writes, for as long as it lives. Measured on a live MN by diffing /proc/<pid>/fd between a monitor forked at startup and one respawned after being killed: the respawned process carried one extra socket, and both ends of that pair were also held by the SSL listener parent. The leak is two descriptors and it does not accumulate, since each respawn forks afresh from the parent; the reason to fix it is that the block is commented "serve only the install monitor" and no longer did, so a monitor's file descriptors depended on whether it was the first one or a replacement. That is the kind of difference that makes a later problem reproduce only on one path. Close both ends in the respawn child. The monitor's own plugin-rescan channel is a different socketpair, created before either fork, and is untouched. Verified afterwards on the same MN: the respawned monitor no longer shares a socketpair with the parent, and still binds xcatiport and serves it, with the SSL listener holding its pid throughout. Not covered by a test. Both the unit suite and the xCAT-test case format work at the level of processes and ports; this is an invariant about file descriptors that needs /proc on a running daemon, and asserting it there would be more fragile than the line it guards. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>