Document "many gotchas" of systemfd/listenfd
I treat it as non-negotiable to support running my daemons under a systemd SystemCallFilter so strict that it's impossible to open new sockets which, so far, has meant listenfd and systemd socket activation. (example)
It'd be very helpful if the Historical Note section in https://actix.rs/docs/autoreload elaborated on "this has many gotchas" so I can either work around them or use Axum instead.
The warning is more about specifically the auto reload use case where I found signal handling to be more difficult to integrate correctly with the systemfd tool than desirable for a beginners guide like this.
I'm not aware of any issues with the listenfd crate or its integration with Actix Web which is what you'd need for the systemd module integration.
Happy to take suggestions on text updates to make this clear.
Perhaps just this minor change:
An old version of this page recommended using a combination of systemfd and listenfd, but systemfd has many gotchas relating to signal handling and was difficult to integrate properly, especially when part of a broader development workflow. We consider watchexec to be sufficient for auto-reloading purposes.
That's almost identical but makes it clear that it's the combination of systemfd and signal handling that causes problems and I think anyone who's looked into signal handling at all is likely to feel that just mentioning it is explanation enough for "don't do that" advice.
(I'm reminded of Linus Åkesson's Hitchhiker's Guide to the Galaxy reference (under "Signal madness") and Vorner's explanation of signal-hook's design rationale.)