samhocevar / rinetd

📡 TCP/UDP port redirector
GNU General Public License v2.0
859 stars 184 forks source link

Rinetd freezes after two reloads with UDP configured #31

Open helge17 opened 2 years ago

helge17 commented 2 years ago

I noticed that every few hours (after some reloads) rinetd on a productive machine became unresponsive. With the follwing test setup i was able to reproduce the behavior:

rinetd 0.73+git20210302.d4e0a60 on Debian Testing (bookworm)

/etc/rinetd.conf:

logfile /var/log/rinetd.log
127.0.0.1     2222/tcp      127.0.0.1  22/tcp
127.0.0.1     1111/udp      127.0.0.1  111/udp

Start rinetd: # /usr/sbin/rinetd -f rinetd: starting redirections...

Log in via ssh through rinetd: $ ssh -p 2222 127.0.0.1

/var/log/rinetd.log: 09/Sep/2022:12:31:32 127.0.0.1 127.0.0.1 2222 127.0.0.1 22 0 0 opened

1st Reload: # kill -HUP 'pidof rinetd'

Rinetd stdout: rinetd: received SIGHUP, reloading configuration... rinetd error: accept(5): Resource temporarily unavailable

/var/log/rinetd.log: 09/Sep/2022:12:32:07 ? 127.0.0.1 2222 127.0.0.1 22 0 0 accept-failed -

=> Rinetd still works (existing ssh session is ok, new sessions can be opened).

2nd Reload: # kill -HUP 'pidof rinetd'

Rinetd stdout: rinetd: received SIGHUP, reloading configuration... rinetd error: accept(5): Resource temporarily unavailable

/var/log/rinetd.log: 09/Sep/2022:12:32:55 ? 127.0.0.1 2222 127.0.0.1 22 0 0 accept-failed -

=> Rinetd hangs: Existing ssh session becomes unresponsive, no new ssh session is possible (port 2222 is open, but does not send any response, no connection to the real destination port 22 is opened).

3th and subsequent Reloads: # kill -HUP 'pidof rinetd'

Rinetd stdout: rinetd: received SIGHUP, reloading configuration... (no "Resource temporarily unavailable")

/var/log/rinetd.log: (nothing)

This is 100% reproducable and also happens when there is no open tcp session during the reload.

When I remove the UDP redirection from rinetd.conf I still get the above messages on every reload ("Resource temporarily unavailable" and "accept-failed", also after the 3th reload), but rinetd behaves normally also after many reloads (existing ssh session works, new sessions possible).