Re: [exim] Debian-Bug not stopping exim

Hi,

Am Mi den 6. Feb 2019 um 10:45 schrieb Evgeniy Berdnikov via Exim-users:
> On Wed, Feb 06, 2019 at 09:47:04AM +0100, Klaus Ethgen via Exim-users wrote:
> > did anybody already debug and fix the problem in debian that exim is not
> > stopped with stop action anymore?
> >
> > Problem is, that /etc/init.d/exim4 seems to call killproc which calls
> > start-stop-daemon to stop the daemon in stop or restart. When the return
> > state is 0 it removes the PIDFILE.
>
> Yes, pidfile is removed on "stop" action. But I see no problem so far.

So far I also don't see a problem.

> > Unfortunately, start-stop-daemon seems to refuse the daemon when given a
> > pidfile.
>
> Do you mean that start-stop-daemon does not search for a process by
> its name if pidfile is given? It's right, but it's unusual situation
> if you have listening daemon running with pid != pidfile.
> You have better to ask yourself how it could happen.

Well, the relevant part of the init-script is:
  if [ -f "$QRPIDFILE" ]; then
    killproc -p "$QRPIDFILE" "$DAEMON"
    # exim does not remove the pidfile
    if [ $? -eq 0 ] ; then rm -f "$QRPIDFILE" ; fi
    log_progress_msg "exim4_queuerunner"
  fi
  if [ -f "$PIDFILE" ]; then
    killproc -p "$PIDFILE" "$DAEMON"
    # exim does not remove the pidfile
    if [ $? -eq 0 ] ; then rm -f "$PIDFILE" ; fi
    log_progress_msg "exim4_listener"
  fi

That looks promising and ok.

Now for the definition of killproc:
   killproc () {
       local pidfile sig status base name_param is_term_sig OPTIND
       pidfile=
       name_param=
       is_term_sig=

       OPTIND=1
       while getopts p: opt ; do
       case "$opt" in
           p)  pidfile="$OPTARG";;
       esac
       done
       shift $(($OPTIND - 1))

       base=${1##*/}
       if [ ! $pidfile ]; then
       name_param="--name $base --pidfile /var/run/$base.pid"
       else
       name_param="--pidfile $pidfile"
       fi

       sig=$(echo ${2:-} | sed -e 's/^-\(.*\)/\1/')
       sig=$(echo $sig | sed -e 's/^SIG\(.*\)/\1/')
       if [ "$sig" = 15 ] || [ "$sig" = TERM ]; then
       is_term_sig="terminate_signal"
       fi
       status=0
       if [ ! "$is_term_sig" ]; then
       if [ -n "$sig" ]; then
           /sbin/start-stop-daemon --stop --signal "$sig" \
           --quiet $name_param || status="$?"
       else
           /sbin/start-stop-daemon --stop \
           --retry 5 \
           --quiet $name_param || status="$?"
       fi
       else
       /sbin/start-stop-daemon --stop --quiet \
           --oknodo $name_param || status="$?"
       fi
       if [ "$status" = 1 ]; then
       if [ -z "$sig" ]; then
           return 0
       fi
       return 3 # program is not running
       fi

       if [ "$status" = 0 ] && [ "$is_term_sig" ] && [ "$pidfile" ]; then
       pidofproc -p "$pidfile" "$1" >/dev/null || rm -f "$pidfile"
       fi
       return 0
   }

But, and that did change somewhen in the past months, start-stop-daemon
seems to _not_ stop exim with that anymore. Both definitions above did
not change for longer times. Just start-stop-daemon did.

I checked, before I do a "/etc/init.d/exim4 stop", the pid file contains
the correct PID of the exim process. And the rights are:
   ~> ll -a /run/exim4
   insgesamt 4,0K
   drwxr-x---  2 Debian-exim Debian-exim  60 Feb  6 09:21 .
   drwxr-xr-x 27 root        root        980 Feb  6 10:14 ..
   -rw-r--r--  1 root        Debian-exim   6 Feb  6 09:21 exim.pid

After the stop, exim is still running but the pid file is gone.

And I get the message on the console:
~> /etc/init.d/exim4 stop
[....] Stopping MTA:/sbin/start-stop-daemon: matching only on non-root pidfile /run/exim4/exim.pid is insecure
[ ok 4_listener.

> > But it does not error out than just return with 0. So the
> > pidfile is gone afterwards.
>
> In this case pidfile was gone BEFORE start-stop-daemon invocation.

Nope.

> This is exceptional situation, it requires manual dignostics.

That is what I do currently.

> It's not good thing to "resolve" such situations automatically
> unless you clearly understand what happens and why it can't be
> resolved in other ways.

Well, it is clearly not a fine situation why since some days a restart
of exim fills my paniclog.

For the record, exim is not restarted for logrotation but from
needrestart or manualy.

So there was a bug introduced in the last few weeks in start-stop-daemon
that I have to find a way around. The current situation is not
acceptable.

Regards
   Klaus
- -- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@???>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C