[Debian-ha-maintainers] Bug#1136573: resource-agents uses pidof but does not depend on procps

[Gioele Barabucci]

Source: resource-agents
Version: 1:4.18.0-1
Usertags: pidof-without-procps

Dear maintainer(s) of resource-agents,

it appears that resource-agents uses `pidof` in its testsuite, or that
at least one of its binary packages uses `pidof` at runtime.
Historically, `pidof` was provided by the Essential package
`sysvinit-tools`, making an explicit dependency unnecessary. However
`pidof` will soon be moved to `procps` and will no longer be part of
the Essential set.

Please add an explicit dependency on `procps`:

* via the `Depends:` field of all binary packages of resource-agents
  that use `pidof` at runtime;
* via the `Build-Depends:` field of resource-agents, if `pidof` is
  used in tests run at build-time;
* via the `Depends:` field of `debian/control/tests`, if `pidof` is
  used in autopkgtests.

To prevent any disruption for users of resource-agents, please add
this dependency now, before `pidof` is moved from `sysvinit-utils` to
`procps`. Alternatively, you could remove all uses of `pidof`.

It is believed that resource-agents uses `pidof` due to the following
code snippets:

```
path: resource-agents_1:4.17.0-2/heartbeat/vmware
# Check for mandatory files presence and consistency
vmware_validate() {
  if [ -z "`pidof vmware-hostd`" ]; then
    ocf_log err "vmware-hostd is not running"
    exit $OCF_ERR_GENERIC


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/svclib_nfslock.in
{
        declare dev family addr maskbits ip_name
	declare lockd_pid=$(pidof lockd)
	declare nl_dir=$1


path: resource-agents_1:4.17.0-2/heartbeat/VIPArip
		if $GREP $OCF_RESKEY_ip $RIPDCONF >/dev/null 
		then
			if pidof ripd >/dev/null
			then
				return $OCF_SUCCESS


path: resource-agents_1:4.17.0-2/heartbeat/redis.in
		elif (( info[loading] == 1 )); then
			sleep "${info[loading_eta_seconds]}"
		elif pidof $(basename "$REDIS_SERVER") >/dev/null; then
			# unknown error, but the process still exists.
			# This check is mainly because redis daemonizes before it starts listening, causing `redis-cli` to fail


path: resource-agents_1:4.17.0-2/heartbeat/redis.in
	pid="$(<"$REDIS_PIDFILE")"
	pidof $(basename "$REDIS_SERVER") | grep -q "\<$pid\>" || return $OCF_NOT_RUNNING
	ocf_log debug "monitor: redis-server running under pid $pid"


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/nfsserver.sh.in
	while : ; do
		pids=$(pidof $1)
		[ -z "$pids" ] && return 0
	 	kill -9 $pids


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/nfsserver.sh.in
	cp -f /var/lib/nfs/statd/sm/* /var/lib/nfs/statd/sm-ha 2> /dev/null
	if pidof rpc.statd &> /dev/null; then
		ocf_log debug "rpc.statd is already running"
		return 0


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/nfsserver.sh.in
	while : ; do
		pids=$(pidof $1)
		[ -z "$pids" ] && return 0
	 	kill $pids


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/smb.sh.in
	# First generate a list of candidate pids.
	pidof $daemonName > $tmpfile
	if [ $? -ne 0 ]; then
		ocf_log debug "kill_daemon_by_arg: no pids for $daemonName"


path: resource-agents_1:4.17.0-2/rgmanager/src/resources/vm.sh.in
	# libvirtd is required for migration.
	#
	pid=$(pidof libvirtd)
	if [ -z "$pid" ]; then
		# attempt to determine if vm is running from pid file
```

Feel free to close this issue if this is a false positive (for example
if this code is in an unreachable code path).

Regards,

-- 
Gioele Barabucci