Bug#782030: stunnel4: Fails to restart on slow/loaded systems

[Ferenc Wágner]

Package: stunnel4
Followup-For: Bug #782030

Here's a patch adding systemd Type=notify support:

--- a/src/ui_unix.c
+++ b/src/ui_unix.c
@@ -107,6 +107,9 @@
 if(signal(SIGINT, SIG_IGN)!=SIG_IGN)
 signal(SIGINT, signal_handler); /* fatal */
 #endif
+#ifdef USE_SYSTEMD
+sd_notify(1,"READY=1");
+#endif
 daemon_loop();
 } else { /* inetd mode */
 CLI *c;

This enables using a systemd service file like

[Unit]
Documentation=man:stunnel4
Description=TLS tunnels for network daemons

[Service]
Type=notify
Restart=always
ExecStart=/usr/bin/stunnel4

[Install]
WantedBy=multi-user.target

after setting foreground = yes in /etc/stunnel/stunnel.conf.
This does not need a PID file (so it's best to remove the patch
creating one by default), which is also useful if one wants to use
systemd directives to manage privileges, for example

User=stunnel4
AmbientCapabilities=CAP_NET_BIND_SERVICE
ExecReload=/bin/kill -HUP $MAINPID

enables reloading of a mostly unprivileged stunnel process with
low-port bindings.  Socket activation could do even better, running
the stunnel process fully unprivileged, but requires splitting the
configuration between the socket unit and stunnel.conf, which is
inconvenient.  The above ExecReload is rudimentary, too, because it
does not wait for the reload to finish.  But you get the idea.
-- 
Regards,
Feri.

Bug#782030: stunnel4: Fails to restart on slow/loaded systems

[Ferenc Wágner]

Control: found -1 3:5.39-2

On Mon, 06 Apr 2015 19:16:24 +0200 Tollef Fog Heen  wrote:

> Nothing here ensures the daemons have actually exited before it tries to
> start the new daemon.
> 
> There's a variant of the same bug in that the init script will return on
> stop before the daemon has actually stopped.  Should be easy enough to
> fix with a loop in killdaemons, or by using start-stop-daemon instead
> which will wait for you.

Unfortunately, this bug is still present and probably wasn't fixed in
the intermediate versions either.  In my reading the killproc function
does not wait for the signalled process to exit, so nothing changed with
the init script rework in this respect.  To make stunnel always lose the
exit race, I recompiled with the following patch:

--- a/src/stunnel.c
+++ b/src/stunnel.c
@@ -309,6 +309,7 @@
 sleep(1); /* to avoid log trashing */
 }
 }
+sleep (10); /* wait before exiting */
 }
 
 /* return 1 when a short delay is needed before another try */

Still, "systemctl stop stunnel4" is instantenous, and leaves behind the
stunnel4 process for 10 seconds.  I tested with the shipped sample
config, with and without the "pid" directive.  Restart also fails:

Jun 20 14:06:01 elm systemd[1]: Stopping LSB: Start or stop stunnel 4.x (TLS 
tunnel for network daemons)...
Jun 20 14:06:01 elm stunnel: LOG5[main]: Terminated
Jun 20 14:06:01 elm stunnel4[1000]: Stopping TLS tunnels: 
/etc/stunnel/sample.conf: stopped
Jun 20 14:06:01 elm systemd[1]: Stopped LSB: Start or stop stunnel 4.x (TLS 
tunnel for network daemons).
Jun 20 14:06:01 elm systemd[1]: Starting LSB: Start or stop stunnel 4.x (TLS 
tunnel for network daemons)...
Jun 20 14:06:01 elm stunnel4[1020]: Starting TLS tunnels: 
/etc/stunnel/sample.conf: started
Jun 20 14:06:01 elm systemd[1]: Started LSB: Start or stop stunnel 4.x (TLS 
tunnel for network daemons).

No errors, but the old stunnel4 process exits 10 seconds later, and no
new one is started.  I wasn't able to capture logs of this, but the new
process couldn't bind its listening sockets while the old one was still
running.  #535924 did a better job on this, this needs investigation.

So I think the init script is still broken.  Actually, an init script in
itself will never be fully correct under systemd because of the default
RemainAfterExit=yes in its SysV compatibility layer.  So providing a
standalone systemd service file would be the best solution.  I'd
recommend adding Type=notify support upstream (should be straightforward)
to avoid the need for PID files and using templated service (and for
bonus points, optionally socket) units for properly managing multiple
config files.  However, as I read, upstream wants to move away from
supporting independent daemons (which is perfectly reasonable, as a
single daemon is multiplexing anyway), so the template stuff could be
left out without significant loss.  #826883 should be linked here.

I'm willing to help with the above if needed.  Unfortunately, this issue
now affects stretch as well, but probably can't be solved via a stable
update, being too fundamental.
-- 
Regards,
Feri

Bug#782030: stunnel4: Fails to restart on slow/loaded systems

[Tollef Fog Heen]

Package: stunnel4
Version: 3:5.06-2
Severity: serious

From the init script:

  force-reload|restart)
echo -n Restarting $DESC: 
killdaemons
sleep 5
startdaemons
echo $NAME.
;;

Nothing here ensures the daemons have actually exited before it tries to
start the new daemon.

There's a variant of the same bug in that the init script will return on
stop before the daemon has actually stopped.  Should be easy enough to
fix with a loop in killdaemons, or by using start-stop-daemon instead
which will wait for you.

Serious since this means restarts will randomly fail.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages stunnel4 depends on:
ii  adduser3.113+nmu3
ii  libc6  2.19-17
ii  libssl1.0.01.0.1k-3
ii  libsystemd0215-14
ii  libwrap0   7.6.q-25
ii  multiarch-support  2.19-17
ii  netbase5.3
ii  openssl1.0.1k-3
ii  perl   5.20.2-3
ii  perl-modules   5.20.2-3

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  none

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org