Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

Mark Hindley mark at hindley.org.uk
Wed Mar 22 18:18:47 GMT 2023

Control: tags -1 upstream


Thanks for your quick work on this.

On Wed, Mar 22, 2023 at 12:40:43PM -0300, Jesse Smith wrote:
> This has been fixed upstream for the upcoming sysvinit 3.07. Would be
> great to get some people testing it before we do an official reelase of
> the 3.07 branch.
> The updated pidof will now return an PID matches for a corresponding
> executable or symbolic link. In other words, if /tmp/sleep is a symbolic
> link to /usr/bin/sleep, then it doesn't matter which path name we use,
> pidof will recognize both names go to the same real program and print
> its PID.

I have just done a local build of 3.06 with a cherry pick of just this hunk of

diff --git a/src/killall5.c b/src/killall5.c
index 992ce3e1..75750d32 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -763,6 +763,11 @@ PIDQ_HEAD *pidof(char *prog)
 				add_pid_to_q(q, p);
+                        else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) )
+                        {
+                            add_pid_to_q(q, p);
+                            foundone++;
+                        }

The patched version still fails to find a running vi process when run as

 pidof $(which vi)

Is that because there are 2 layers of symlinks?

 /usr/bin/vi ->  /etc/alternatives/vi ->  /usr/bin/vim.basic


More information about the Debian-init-diversity mailing list