== A gotcha with _inetd_/_xinetd_ and popular UDP services

We have historically had a small problem with our _inetd_s: every so
often when we attempted to restart it with a SIGHUP to make it pick up a
configuration change, it would fail to bring up an important UDP-based
service we need, reporting a failure to bind to the UDP port.

(We saw the same problem with _xinetd_; I'm using '_inetd_' as as a
generic term.)

What was probably happening is that when this would happen, _inetd_ had
just spawned the program to handle the service and it was still running
when _inetd_ itself was restarting. As part of restarting, most versions
of _inetd_ close each TCP or UDP port they were listening on and then
reopen and rebind it. (Technically _inetd_ closes the file descriptors
that are the listening server sockets.)

For TCP-based services that are running at the time, this is no problem.
When _inetd_ spawns a program to handle a TCP service the program is
handed a connected socket, which we can label as '_(dest-ip, dest-port,
my-ip, my-tcp-port)_', which does not conflict with _inetd_ re-binding
to the listening TCP port, '(((*, *, *, my-tcp-port)))'.

But UDP-based services are different. Because UDP is connectionless,
the only thing _inetd_ can give to programs that it starts to handle
UDP services is *a full copy of its own listening socket*, ie
'(((*, *, *, my-udp-port)))'. So when _inetd_ attempts to re-bind
a new listening UDP port, it is trying to recreate '(((*, *, *,
my-udp-port)))' and the kernel refuses because it already has one
of those around and it can't have a second (for [[sensible reasons
../programming/WhyPortBindingRestriction]]).

We ran into the problem often enough to be problematic because this UDP
service was reasonably frequently used (most UDP services that people
have _inetd_ handle are only infrequently used; people tend to make
frequently used UDP stuff into actual daemons).

(Because some of the SIGHUP restarts were automatic, it's not quite
good enough to SIGHUP _inetd_ repeatedly until it came up right; one
would have to write the auto-restart script so that it knew when the
UDP port was supposed to be bound to start with and when it wasn't.)