[From nobody Fri May 22 11:53:11 2026 Received: (at submit) by bugs.debian.org; 13 May 2026 23:31:50 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-104.5 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOURLA, FROMDEVELOPER,MISSING_HEADERS,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 67; hammy, 150; neutral, 83; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <gioele@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:58950) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <gioele@debian.org>) id 1wNJ3O-00CR4j-13 for submit@bugs.debian.org; Wed, 13 May 2026 23:31:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Subject:From:Message-ID:Date:Reply-To: To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=Ea4DZc5vhqJQOe6s1FONUZhETlIfd6ewEXHX+UivmJI=; b=t/VWS5thIQ4rhFdIyob9y6uk1f t3QowXj8bCJLRK3wfhr1Kqjop6q34lipF+2cHtcKT7iyCXBvkMB+ixU3TlpW6kCuXe+/nWvDy3e73 PYbzyAriy0ur/riZvlrG1Gau87mSQorXaWJpkdyYc+6s+l0AhUVb9N1DoNaQo4UxruTURc8n2uCi0 sqNzKvgelEofNB1XI1hfXKJRrSh23efQfVP2J9cylvhqmCCI6c24ac+/7obqOyWpf5Ot8/dAVh4ep Yb4hcozUiPefOBE2hxAkNp78/oJDgVbAbYfU4NG2Da/JtUIV5qXthAI4i4cXB/soEtbdkqJskqBku +WcWmt6w==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <gioele@debian.org>) id 1wNJ3M-003WJR-2r for submit@bugs.debian.org; Wed, 13 May 2026 23:31:49 +0000 Date: Thu, 14 May 2026 01:31:48 +0200 Message-ID: <3d930585be1cae7d76173ee349b197b2@debian.org> From: Gioele Barabucci <gioele@debian.org> Subject: resource-agents uses pidof but does not depend on procps X-Debian-User: gioele Delivered-To: submit@bugs.debian.org 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 ]