I too have had this problem for a while. Stunnel4 operates perfectly (apart from infrequent random 100% usages requiring killing) but the /etc/init.d/stunnel4 script reports those erroneous messages.
I think, because of that (and hence returning a failure code), apt didn't think stunnel4 had fully installed correctly, so set about trying to reconfigure and restart the daemon on every apt-get install/upgrade. Each attempt was met by the same init.d script error messages.
So, given it works fine otherwise, I just hacked up a nasty solution to get things working and to stop this stunnel4 reconfiguring on every software upgrade. In /etc/stunnel/stunnel.conf you can see the location of your pid file. If you take the chroot value (/var/lib/stunnel4 for me) and append the pid value (/stunnel4.pid), you get the location of your stunnel4 pid lock (/var/lib/stunnel4/stunnel4.pid for me).
Editing /etc/init.d/stunnel4, I set DEFAULTPIDFILE to /var/lib/stunnel4/stunnel4.pid (the correct location, instead of /var/run/stunnel4.pid, which is never created) and then added a test to see if the pid lock file exists just before it tries to start stunnel. If it does, it simply doesn't bother trying to start stunnel again.
With that in hand, you can /etc/init.d/stunnel4 restart, and then do an apt-get install *whatever*. Given the script no longer does an "exit 1", apt thinks the configuration/launch succeeded, and stunnel4 shows as being properly installed.
I don't know if this is a particularly good hack to recommend, but it seems to do the job ok for me. I suppose if an old pid file gets left there, then stunnel4 won't start :) but you can just comment the changes out anyway.
My startdaemons() method in /etc/init.d/stunnel4 now looks like:
startdaemons() {
if ! [ -d /var/run/stunnel4 ]; then
rm -rf /var/run/stunnel4
install -d -o stunnel4 -g stunnel4 /var/run/stunnel4
fi
# Checks to see if a lock exists for stunnel4; if it does, it's already running
# and we don't need to start it again.
if [ ! -e $DEFAULTPIDFILE ]; then
# It isn't already running; let's try to start it now
for file in $FILES; do
if test -f $file; then
ARGS="$file $OPTIONS"
if $DAEMON $ARGS; then
echo -n "[Started: $file] "
else
echo "[Failed: $file]"
echo "You should check that you have specified the pid= in you configuration file"
exit 1
fi
fi
done;
I too have had this problem for a while. Stunnel4 operates perfectly (apart from infrequent random 100% usages requiring killing) but the /etc/init. d/stunnel4 script reports those erroneous messages.
I think, because of that (and hence returning a failure code), apt didn't think stunnel4 had fully installed correctly, so set about trying to reconfigure and restart the daemon on every apt-get install/upgrade. Each attempt was met by the same init.d script error messages.
So, given it works fine otherwise, I just hacked up a nasty solution to get things working and to stop this stunnel4 reconfiguring on every software upgrade. In /etc/stunnel/ stunnel. conf you can see the location of your pid file. If you take the chroot value (/var/lib/stunnel4 for me) and append the pid value (/stunnel4.pid), you get the location of your stunnel4 pid lock (/var/lib/ stunnel4/ stunnel4. pid for me).
Editing /etc/init. d/stunnel4, I set DEFAULTPIDFILE to /var/lib/ stunnel4/ stunnel4. pid (the correct location, instead of /var/run/ stunnel4. pid, which is never created) and then added a test to see if the pid lock file exists just before it tries to start stunnel. If it does, it simply doesn't bother trying to start stunnel again.
With that in hand, you can /etc/init. d/stunnel4 restart, and then do an apt-get install *whatever*. Given the script no longer does an "exit 1", apt thinks the configuration/ launch succeeded, and stunnel4 shows as being properly installed.
I don't know if this is a particularly good hack to recommend, but it seems to do the job ok for me. I suppose if an old pid file gets left there, then stunnel4 won't start :) but you can just comment the changes out anyway.
My startdaemons() method in /etc/init. d/stunnel4 now looks like:
startdaemons() {
if ! [ -d /var/run/stunnel4 ]; then
rm -rf /var/run/stunnel4
install -d -o stunnel4 -g stunnel4 /var/run/stunnel4
fi
# Checks to see if a lock exists for stunnel4; if it does, it's already running
# and we don't need to start it again.
if [ ! -e $DEFAULTPIDFILE ]; then
# It isn't already running; let's try to start it now
for file in $FILES; do
if test -f $file; then
ARGS="$file $OPTIONS"
if $DAEMON $ARGS; then
echo -n "[Started: $file] "
else
echo "[Failed: $file]"
echo "You should check that you have specified the pid= in you configuration file"
exit 1
fi
fi
done;
# end of pid test
fi
}