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 <[email protected]> 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@node-1 ~]# ps ax | grep corosync
> 1648 root 0:51 /usr/sbin/corosync
>
> [root@node-1 ~]# pidof corosync
> 1648
> [root@node-1 ~]# echo $?
> 0
>
> [root@node-1 ~]# pidof /usr/sbin/corosync
> [root@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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
