💾 Archived View for acidic.website › musings › lost-art-xinetd.gmi captured on 2023-07-10 at 13:23:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Date: 2020-05-27
State: Done
Simply provide a port on which a service should be listening, and Xinetd will listen on that port, accept a new, incoming connection, and then spawn a process containing application logic with stdin and stdout of the application having access to input from Xinetd (usually with information about the connection and incoming socket data) and output respectively (so printing to standard output is effectively writing to the socket).
My Gemini "server" (if you can call it that) is built on-top of stunnel and Xinetd. While configuring everything, I went looking for Xinetd documentation. At my job I work heavily with nginx and mysql, and have come to expect broad (if not thorough) documentation from tools I work with. I recently introduced m4 at work and really enjoyed its deep documentation and illustrative examples (and I used a browser stylesheet to theme the page to make it better on my eyes), so I went into Xinetd expecting more of the same.
Red Hat documentation is didactic and has examples, but is quite brief. Xinetd has a manual page. Unfortunately, there seems to be no collection of good patterns to use with Xinetd, templates for setting up services, or even common footguns encountered using Xinetd.
Xinetd is very useful and is used to deliver some core -nix services (though maybe systemd has replaced this?? I don't really follow systemd development much.) Some folks I imagine will think Xinetd is simple enough that examples aren't necessary, the manual page being complete. To that I disagree; the manual page still forces the user to think through multiple cases. I would love to see templates premade, so the user can read the template and think through it *once* then abstract it away for future use.
I found some examples for basic services already on the OS and tried to read through them and corroborate them with the man page. (I really need to find (or make) a way to read remote man pages through emacs.) After that I stood up Xinetd, and played around with it to make sure it was doing what I expected it to do. And it did.
Logging on a traditional long-running server process is a simple log file. For Xinetd, I didn't know what to look at. The manual has a few options on both syslog outputs and file outputs. Stunnel also produces logs for me, so I need to decide which to keep. For now it'll probably be Stunnel, but only time will tell.
The whole thing feels like a forgotten relic. When I search for Xinetd on the web, I sometimes feel as if I'm an archaeologist, walking through ruins. The only thing you can find for Xinetd are some crusty old manpages and a few pages in an OS manual. There are a few blog posts, but they rarely dive into the reasoning behind using Xinetd or details of the daemon. (N.B. Is this by design? Does this come from a culture of "read the source?" If that were the case, I really wish it were printed loudly on the tin.) So I'm left to wonder, does nobody use Xinetd anymore? And why? Sure Xinetd did not make it to C10k, but how many people when writing PoCs actually need the scale of a dedicated network daemon? I'm saddened that Xinetd isn't used more.