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>
xCAT
xCAT is a toolkit for deployment and administration of clusters of all sizes.
The xCAT sunset was only a quick eclipse
Dear xCAT Community,
The xCAT sunset has changed course. VersatusHPC has been invited to join the xCAT Consortium, and future development will move toward direct upstream contributions coordinated with the Consortium and its existing member companies.
That matters most for Enterprise Linux 10 (EL10). EL10 support is coming to xCAT, restoring a future operating-system path for sites that still rely on xCAT. This is an important change from the previous sunset guidance, where the lack of an EL10 path was one of the strongest reasons to move away from xCAT.
The xCAT Consortium continues to recommend Confluent as the long-term successor to xCAT, and that remains the Consortium position. Users planning new cluster-management deployments should evaluate Confluent and its xCAT comparison documentation.
At the same time, xCAT is no longer sunsetted. The Consortium and participating companies will continue updating xCAT while there is community and user demand for it.
In summary:
- xCAT development is continuing upstream through the Consortium and participating companies.
- Enterprise Linux 10 support is coming.
- Confluent remains the Consortium-recommended successor and migration path.
- xCAT updates will continue while there is community and user demand.
We want to thank the xCAT Consortium and community for keeping this project moving. The sun went behind the moon for a moment, but xCAT is still here.
For more information on Confluent and how to get started, please visit the Confluent: Project Page, Documentation or Confluent vs xCAT comparison.
With thanks,
The xCAT Consortium
Documentation
xCAT Documentation is hosted on Read The Docs: https://xcat-docs.readthedocs.io
Status
| xCAT Version | Build Status |
|---|---|
| Latest (master branch) | |
| Stable (latest release) |
Looking for older versions?
Open Source License
xCAT is made available under the EPL license: https://opensource.org/licenses/eclipse-1.0.php
Developers
Want to help? Check out the developers guide!