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

[J Mo]

Go for it. It's been years since I filed that bug.



On 12/29/18 10:34 AM, Dmitry Bogatov wrote:
> 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?