Execution in script leaves behind many defunct processess

[Snowman-25]

Hi,

I've written the following simple script, which creates defunct xdotool processes (Zombies): Its purpose is to monitor the color of the pixel choosen at the start of the script and click if a specified color is shown (and log an according message)

#!/bin/bash
echo Press a key to start && read -sn1
eval $(xdotool getmouselocation --shell)
echo Scanned location is @ X:$X Y:$Y
while [ 1 ]; do
        COLOR=$(xdotool mousemove $X $Y sleep 0.1 click 1 mousemove restore & echo $( grabc 2>/dev/null ))
        if [[ "$COLOR" = "#058f00" ]]; then     # Bar is green
                xdotool mousemove $X $Y sleep 0.01 mousedown 1 sleep 0.2 mouseup 1 sleep 0.01 mousemove restore
                echo "Clicked at $(date +%T)"
        fi
        if [[ "$COLOR" = "#000800" ]] || [[ "$COLOR" = "#030403" ]] || [[ "$COLOR" = "#02080e" ]]; then # Dark screen. Misclicked?
                xdotool mousemove $X $Y sleep 0.01 mousedown 1 sleep 0.2 mouseup 1 sleep 0.01 mousemove restore
                echo "Misclicked at $(date +%T)"
        fi

        read -n 1 -t 0.4 -s && echo PAUSED. Press 'Q' to exit or any key to continue && read -sn1 && echo Continuing...
        if [[ "$REPLY" = "q" ]]; then
                break
        fi
done

For some reason, this creates a zombie process with each repetition of the loop. It also doesn't die with the parent, so my only choice, once the process-limit has been reached, is to reboot. I'm using CentOS 7 (inside a docker-Container).

[erjiang]

Does running an init process in your container as the primary process solve the issue? Could it be related to https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

[Snowman-25]

Thanks for the suggestion, but I'm just using a container someone else built. I'm not knowledgable enough in Docker to re-build it with baseimage-docker. The Container I'm using is currently running on expect.

But it seems like xdotool isn't exiting properly in some way, causing this in the first place.

[Snowman-25]

Okay, I've briefly looked into the docker system and found that all I had to do was make a copy of the container via docker commit and add --init to the initial docker run command. And this did, in fact, fix the issue. Thank you @erjiang

Still feels like xdotool shouldn't rely on init to reap the process, however. Firefox and other processes running in the container do NOT behave like this.

[jordansissel]

I looked over your script, and I’m not sure exactly what to suggest. A Unix process cannot reap itself, so there’s not much xdotool can do here to help. This responsibility belongs to the parent process (bash, in this case) or Pid 1 (usually init).

On Sat, Feb 27, 2021 at 4:40 AM Snowman-25 notifications@github.com wrote:

Okay, I've briefly looked into the docker system and found that all I had to do was make a copy of the container via docker commit and add --init to the initial docker run command. And this did, in fact, fix the issue. Thank you @erjiang https://github.com/erjiang

Still feels like xdotool shouldn't rely on init to reap the process, however. Firefox and other processes running in the container do NOT behave like this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordansissel/xdotool/issues/291#issuecomment-787066743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAF2XNG2CRAJ7NQGB2T6TTBDR2ZANCNFSM4O4KHZ5A .

[FascinatedBox]

I might be wrong but I think the bug is in the script that @Snowman-25 wrote.

        COLOR=$(xdotool mousemove $X $Y sleep 0.1 click 1 mousemove restore & echo $( grabc 2>/dev/null ))

I think & should be && here.