stunnel4 init.d script reports startup failures with pid=error message even when not so

Bug #137472 reported by Tatiana
42
This bug affects 9 people
Affects Status Importance Assigned to Milestone
stunnel4 (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Binary package hint: stunnel4

From an ubuntu edgy install.

Revision history for this message
Tatiana (tatiana) wrote :

 $ dpkg -S /etc/init.d/stunnel4
stunnel4: /etc/init.d/stunnel4
$ dpkg -l|fgrep stunnel4
ii stunnel4 4.150-7 Universal SSL tunnel for network daemons

Revision history for this message
Tatiana (tatiana) wrote :

startdaemons() {
  if ! [ -d /var/run/stunnel4 ]; then
    rm -rf /var/run/stunnel4
    install -d -o stunnel4 -g stunnel4 /var/run/stunnel4
  fi
  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;
}

Revision history for this message
Nicola Rosati (supernaicol) wrote :

I don't know if my case is related to yours, because I don't have the necessary skills to inspect the init.d script, but I cannot start stunnel4 with "sudo /etc/init.d/stunnel4 start", so neither stunnel starts when i boot my workstation.

Instead "sudo stunnel4" works perfectly.

Best regards

Revision history for this message
Nicola Rosati (supernaicol) wrote :

I've resolved my issue simply setting "ENABLED=1" instead of "ENABLED=0" in the file /etc/default/stunnel4.
Tatiana, I still don't know if your case is affected by the same issue, but my problem now seems quite stupid. To be honest, it seems also quite stupid that file didn't enable the service, and that I had to search in the instructions given by the library department of my university to solve the problem (BTW: FANTASTIC! Detailed instructions for Ubuntu 7.* and Gentoo).

Revision history for this message
Daniel T Chen (crimsun) wrote :

Reproducible in 8.04.1 and current 8.10.

Changed in stunnel4:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Adrian Busolini (aab-cs) wrote :

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
}

Revision history for this message
Peter (pesto) wrote :

I got following error message at the startup of stunnel4 on karmic "You should check that you have specified the pid= in you configuration file". I'm using stunnel for nntps (119/563).

I checked port 119 and found, that cyrus is using port 119 too:

netstat -tupan | grep ':::119'
tcp6 0 0 :::119 :::* LISTEN 1504/cyrmaster

I don't know why, but nntp is activated in /etc/cyrus.conf by default. Comment out the nntp service in cyrus:

#nntp cmd="nntpd -U 30" listen="nntp" prefork=0 maxchild=100

After that stunnel4 started without an error. Conclusion: check if no other process is using the ports you want to use with stunnel.

Revision history for this message
valkyr (locki) wrote :

On Maverick the same error occurs.

It is however to do with the message before the one about the PID, complaining of the missing SSL certificate needed to run stunnel.

A guide to certificates, and how to generate one can be found here : http://www.stunnel.org/faq/certs.html

I guess a cert. isn't packaged because everyone needs a unique one.

Revision history for this message
Joey Imbasciano (joey-imbasciano) wrote :

This bug was reported in 2007, confirmed in 2008 and is still not fixed? I can confirm this is still affecting Ubuntu 8.04:

ii stunnel4 3:4.21-1 Universal SSL tunnel for network daemons

Any plans to fix this?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.