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
Jesse,
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
b70b2776
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);
foundone++;
}
+ else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) )
+ {
+ add_pid_to_q(q, p);
+ foundone++;
+ }
}
}
--
2.39.2
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
Mark
More information about the Debian-init-diversity
mailing list