Bug#810018: procps: Please (re)consider shipping procps pidof

[Andrew Bower]

Hi all,

First I would like to thank Gioele, Andreas, Craig and others who have
put a significant amount of effort into analysing the impact of this
transition, contributing changes to packages over a number of years and
considering the effect on users of init systems in which they themselves
have no (at most) interest. I appreciate that consideration and do not
wish to take it for granted!

Mark has suggested I comment on this thread but do please note that my
views don't necessarily reflect his or anyone else's.


On Thu, Jan 07, 2016 at 12:53:12PM +0100, Andreas Henriksson wrote:
> I've also spent some time on researching the pidof users and the main
> user seemed to be direct invokations from init scripts. These could
> benefit from being converted to LSB "pidofproc" helper function (which
> falls back on executing pidof if available though).

This, I think, is the residual work not covered by the transition plan
and is my main subject below.


On Mon, Apr 27, 2026 at 10:47:55PM +0200, Gioele Barabucci wrote:
> Dear procps maintainer,
> dear sysvinit maintainers,
>
> while we try to reach consensus in #1131136 on the best way to remove the
> Essential bit from `sysvinit-utils`, I think we can focus on a simpler task:
> moving `pidof` from `sysvinit-utils` to `procps`.
> 
> Do you procps and sysvinit maintainers agree with the following plan?

While I am not convinced that the benefits of this and the #1131136
transitions, such as they are (and they seem largely aesthetic to me),
outweigh the costs, and I do not find the case that there is a technical
imperative in switching to the same implementation as 'everyone else'
compelling, I would like to help this transition succeed and do agree
that ultimately it would be nice for pidof to come from the same source
as the other p* family of tools.

In general I think using pidof and the other p* tools in a script is
inherently flaky so I hope that those of us invested in the d-i-d
ecosystem will use this opportunity to try to improve some of the
affected initscripts not to rely on such unreliable process tracking
approaches but this should not need to be a blocker to the transition if
some coarser-grained defences are also deployed.

> The plan:
> 
> 1. I will announce a MBF on d-devel@, with a request for the 94 packages
> that use `pidof` at runtime to add `Depends: procps` (the email template can
> be seen at [2], the dd-list at [3]).

Can I just confirm (as it looks to me) that this covers all runtime
usage *except* for

 a) direct usage in an initscript, and
 b) indirect usage in an initscript via pidofproc where a PIDFILE is
    *not* defined or cannot be reliably guessed?

> Does this sound right? Is anything missing?

Considering the above two cases for initscript, which mercifully are not
as numerous as I first thought, how should we mitigate them?

Here are some options:

1. [ sysvinit -> procps (global solution) ]

Make sysvinit-(core|utils) depend on procps. (Does not cover runtime
usage like initless containers.) I would strongly object to this because
it is too large a dependency to bring in for all sysvinit installations
or other inits that fall back to initscripts.
* No thanks *

2. [ <package> -> procps (per-package solution) ]

The next quick fix idea would be introducing a dependency from the
affected packages, similarly to the proposed MBF for the other types of
runtime dependency. This would be a reasonable fallback position if we
can't do better.
* Good fallback solution *

3. [ dpkg (partial global solution) ]

With Guillem's kind suggestion from 2023 to make start-stop-daemon's
internal pid-of logic available as a first class operation, the
pidofproc() implementation in init-functions could use this, dealing
with all the category 'b' cases transparently (although since I wrote
this, I see only three affected packages). This could also help with
category 'a' cases with a change in the package needed, or *possibly*
transparently by overriding pidof in the shell, iff agreeable - this
might be more fragile.
* Yes please, this would be really good, possibly additionally to other
parts of the solution. *

4. [ improve initscripts (per-package solution) ]

In increasing order of preference and work:
   i. not to need pidof, by making sure an appropriate
      PID file is used.
  ii. to use pidofproc instead of pidof directly.
 iii. to use status_of_proc instead of pidofproc.
  iv. to use aggregate s-s-d operations instead where direct usage is
      avoidable.
   v. to use init-d-script instead.
* Could be a backlog task for d-i-d team, doesn't need to block
transition if package covered by (1), (2) or (3). *

I think option (2) above, dependencies from affected packages to procps,
is sufficient to give a green light to the transition, and hopefully we
can do better than this with (3) and (4) in parallel.

>From my initial attempt at a sweep (could be flawed), these are the
affected packages in sid. This includes some that have been removed from
testing.

AFFECTED PACKAGES

(sorry these are scripts not packages - will need to map back)

* 35 scripts calling pidof directly in initscript:

and
apache2
apcupsd
conman
corosync
corosync-notifyd
dhcp-probe
dns-flood-detector
exim4
fcoe-utils
firebird3.0
firebird4.0
garb
mountall.sh
munge
nagios4
nfs-common
openafs-client
pacemaker
pacemaker_remote
pandorafms-agent
powerman
proftpd
radosgw
samhain
scanbd
shoelaces
slurmctld
slurmd
slurmdbd
swupdate
trousers
virtualbox
vsftpd
yaskkserv

* 3 packages calling pidofproc where pidof fallback seems likely

swupdate
oc2b
cyrus-imapd

(7 other packages call pidofproc without specifying a PID file but the
PID file can be determined by pidofproc from the daemon name.)