ash process — which invoked a background pipe — becomes a ghost process after exiting?

[shunf4]

Running this script with busybox ash:

#!/bin/bash

echo my pid $$

sleep 30 | cat &

echo exiting

exit

shows:

C:\Users\shunf4\bb-proc-test>busybox ash test.sh
my pid 23508
exiting

Now PID 23508 should have already exited.

But busybox ps still sees it, not as an actual process, but as other processes' parent:

C:\Users\shunf4\bb-proc-test>busybox ash -c "ps | grep 23508"
24404 23508 shunf4    0:00  0:06   sleep 30
23972 23508 shunf4    0:00  0:06   cat
17628 22568 shunf4    0:00  0:00   ash -c ps | grep 23508
24900 17628 shunf4    0:00  0:00   grep 23508

And detecting the process by kill -0 succeeds:

C:\Users\shunf4\bb-proc-test>busybox kill -0 23508

C:\Users\shunf4\bb-proc-test>echo %errorlevel%
0

This seems not typical behaviour of UNIX-like processes. Is this working as intended or acceptable? Thanks.

[rmyorston]

On a traditional UNIX system the children of an exited parent would be reassigned to PID 1. On my modern Linux system with systemd they get reassigned to some process that seems to act as PID 1 for my session.

Windows is, of course, different. Your process 23508 has exited, so it doesn't itself appear in the output of ps, but its children still hold references to it as their parent.

Those references aren't very useful, as there's not much you can do with an exited process. Reporting a fake PID 1 as the parent in such cases would be more consistent with how similar UNIX-like features are handled in busybox-w32.

The issue with kill -0 still seeing the exited process is a bug.

Expect fixes in due course.

[rmyorston]

OK, orphaned processes now have a parent PID of 1 and kill fails for processes that have exited.

Try the latest prerelease (PRE-5344 or above).