[PATCH 04/12] hwsim: Use pgrep instead of ps

[Benjamin Berg]

Hi,

On Sat, 2024-01-13 at 20:04 +0200, Jouni Malinen wrote:
> On Mon, Dec 25, 2023 at 12:21:01PM +0200, Andrei Otcheretianski
> wrote:
> > The ps command as shipped by busybox does not support the "command"
> > column. Change the code to use pgrep instead which will work fine
> > in all
> > environments.
> 
> Something strange happens with this in my test setup..
> 
> > diff --git a/tests/hwsim/test_ap_eap.py
> > b/tests/hwsim/test_ap_eap.py
> > @@ -7607,20 +7607,15 @@ def
> > test_ap_wpa2_eap_psk_mac_addr_change(dev, apdev):
> > -    cmd = subprocess.Popen(['ps', '-eo', 'pid,command'],
> > stdout=subprocess.PIPE)
> > -    res = cmd.stdout.read().decode()
> > +    cmd = subprocess.Popen(['pgrep', '-nf', 'wpa_supplicant.*' +
> > dev[0].ifname], stdout=subprocess.PIPE)
> 
> This call ends up printing "pgrep: uptime" in stderr and there is no
> stdout response.

Looks like older procps versions (pgrep 3.3.17 at least) interpret an
uptime of less than 1 seconds as an error condition. This seems to be
fixed in 4.x, but we probably shouldn't rely on that.

I guess I'll just add a "sleep 1" into start.sh.

> > +    res = cmd.stdout.read().decode().strip()
> >      cmd.stdout.close()
> >      pid = 0
> > -    for p in res.splitlines():
> > -        if "wpa_supplicant" not in p:
> > -            continue
> > -        if dev[0].ifname not in p:
> > -            continue
> > -        pid = int(p.strip().split(' ')[0])
> > -    if pid == 0:
> > -        logger.info("Could not find wpa_supplicant PID")
> > -    else:
> > +    if res:
> > +        pid = int(res.strip())
> 
> That strip() part here seems unnecessary.

Sure, will remove that.

> >          logger.info("wpa_supplicant PID %d" % pid)
> > +    else:
> > +        logger.info("Could not find wpa_supplicant PID")
> 
> That else case would leave pid == 0 and that is not going to go well in
> the end of this test case with os.kill(pi, signal.SIGSTOP).. I
> understand that this is mostly unrelated to the changes here, but since
> these change broke determination of the PID, I noticed this as the VM
> just getting completely stuck.

Hah, yes, lets use Exception("...") here instead.

Benjamin