Using 'pidof' with Absolute Path to Process

Marc Smith msmith626 at gmail.com
Wed Jun 12 13:12:51 UTC 2019


Okay, yeah, I'm lost... I see the code where the compare happens, and
it's the same in both Busybox versions:

busybox-1.26.2/libbb/find_pid_by_name.c -> find_pid_by_name()
...
        if (comm_match(p, procName)
        /* or we require argv0 to match (essential for matching
reexeced /proc/self/exe)*/
         || (p->argv0 && strcmp(bb_basename(p->argv0), procName) == 0)
        /* or we require /proc/PID/exe link to match */
         || (p->exe && strcmp(bb_basename(p->exe), procName) == 0)
        ) {
            pidList = xrealloc_vector(pidList, 2, i);
            pidList[i++] = p->pid;
        }
...

If I remove the bb_basename() call from either p->argv0 or p->exe then
this works the way I've always expected/known it to work... what's
even stranger, if I build the original 1.26.2 Busybox source that I've
used for years and always passed the absolute path of a running binary
to it (and had it return PID's with the absolute path), then SCP that
binary up to a machine in say root's home directory and create the
"pidof" sym link to it, it does NOT work as I expect!?

I'm not getting this one... looking at the code and adding monitor
statements, on my new builds with 1.30.1 the 'pidof' applet functions
as it should according to source code. But on old builds using 1.26.2
'pidof' always returns PID's when given an absolute path. Perhaps it
was just a fluke all those years and something wonky in our builds...
I don't know.

I can obviously patch this for our builds and make it work the way
I've always known/expected it to work, but wondering if any one else
out there has any comments (I'm sure I sound crazy). FWIW when using
pidof from procps-ng 3.3.15 on my Fedora machine, giving it an
absolute path to a running program DOES return PID's.

--Marc

On Tue, Jun 11, 2019 at 2:07 PM Marc Smith <msmith626 at gmail.com> wrote:
>
> Hi,
>
> We previously used Busybox 1.26.2 in our project and just recently
> upgraded to Busybox 1.30.1. I noticed a change in the 'pidof'
> behavior... previously we could give the absolute path of a running
> program to 'pidof' and it would work properly (exit 0 and return PID's
> of matching processes). But with 1.30.1 it seems to no longer work
> this way:
> [root at node-1 ~]# ps ax | grep corosync
>  1648 root      0:51 /usr/sbin/corosync
>
> [root at node-1 ~]# pidof corosync
> 1648
> [root at node-1 ~]# echo $?
> 0
>
> [root at node-1 ~]# pidof /usr/sbin/corosync
> [root at node-1 ~]# echo $?
> 1
>
> I looked at the source comparing both versions and I don't see any
> relevant changes in procps/pidof.c nor find_pid_by_name() of
> libbb/find_pid_by_name.c so I suspect the change is in procps_scan()
> (of libbb/procps.c) which is a little more complex.
>
> I'll continue sifting through the code to see if I can find the
> change, but figured it'd be worthwhile to ask those on here that are
> closer to the code that might happen to know. Interested to know if
> the change is intentional, or not so I can adapt our project (if
> needed).
>
> Many thanks for the great work on Busybox!
>
> --Marc


More information about the busybox mailing list