URL:
<https://savannah.gnu.org/bugs/?65890>
Summary: xargs keeps child processes in zombie state before
starting a new process
Group: findutils
Submitter: pcpa
Submitted: Tue 18 Jun 2024 05:18:32 PM -03
Category: xargs
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Release: None
Discussion Lock: Any
Fixed Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Tue 18 Jun 2024 05:18:32 PM -03 By: Paulo César Pereira de Andrade
<pcpa>
This is a copy of the report at https://issues.redhat.com/browse/RHEL-27230
----
User has a shell script in the pattern:
tail -n0 -F /var/log/messages | stdbuf -i0 -o0 grep -o ... | stdbuf -i0 -o0
awk ... | stdbuf -i0 -o0 awk ... | stdbuf -i0 -o0 xargs -n1 /path/to/handler
A sample reproducer is:
term1# xargs -n1 echo
test
test
foo
foo
term2# ps ax | grep Z
PID pts/0 Z+ 0:00 [echo] <defunct>
I understand the root cause is because xargs has the code:
/* Make sure to listen for the kids. */
signal (SIGCHLD, SIG_DFL);
and this means it does not synchronously handle SIGCHLD.
There is also the code:
/* Before forking, reap any already-exited child. We do this so
that we don't leave unreaped children around while we build a
new command line. For example this command will spend most
of its time waiting for sufficient arguments to launch
another command line:
seq 1 1000 | fmt | while read x ; do echo $x; sleep 1 ; done |
./xargs -P 200 -n 20 sh -c 'echo "$@"; sleep $((1 + $RANDOM % 5))'
sleeper
*/
wait_for_proc (false, 0u);
It is understood that changing this might require a significant rework of how
xargs work.
The reproducer should be a very uncommon usage, as input usually should be
very fast, or xargs not used in the way in the user script, and instead use
some shell loop construct.
Still, this might be considered a valid usage of xargs, and the process in
zombie state looks as if something wrong is happening.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65890>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
