Bug#822674: sysvinit-utils: /lib/init/init-d-script do_status() probably needs to specify -p $PIDFILE

[Dmitry Bogatov]

control: tags -1 +confirmed

[2016-04-26 03:52] J Mo <jmomo at jmomo.net>
> I am troubleshooting a problem with the courier package suite
> (courier-imap as example).
> 
> I found that in /lib/init/init-d-script, the do_status() function
> calls status_of_proc() without the -p argument, leaving the PIDFILE to
> be assumed by pidofproc. This, despite the case that init-d-script
> makes it's own assumption and declarat ion about what the daemon
> PIDFILE should be.
> 
> In any case where the PIDFILE declared in the init script is different
> from what pidofproc assumes it to be, failure occu rs because the
> assumed PIDFILE does not exist.
> 
> I would suggest altering the do_status() func from: status_of_proc
> "$DAEMON" "$NAME" && return 0 || return $?
> 
> To: status_of_proc "$DAEMON" "$NAME" -p "$PIDFILE" && return 0 ||
> return $?
> 
> While I'm at it, I don't understand the functionality of "&& return 0
> || return $?". This could be removed and there woul d be no change in
> behavior. Is this an artifact of history?
> 
> In that case: status_of_proc "$DAEMON" "$NAME" -p "$PIDFILE"
> 
> My one concern is regarding the possibility of PIDFILE=none being set
> in the init script. If it's necessary (I can't thin k of a reason why)
> to maintain the current behavior of not feeding the -p argument to
> status_of_proc, we could do:
> 
> 	status_of_proc "$DAEMON" "$NAME" ${PIDFILE:="-p $PIDFILE"} &&
> 	return 0 || return $?
> 
> However, if there is no PIDFILE set, a more rational thing to do would
> seem to be to never run status_of_proc in the firs t place since you
> can't get status on something that isn't running (or didn't leave a
> PID file behind).

I find it reasonable. Any objections to applying this patch?