xdg-open zombie process remains by default in WSL2 after click.launch()
Description
When calling click.launch(<url>) from within WSL2 (specifically Ubuntu-20.04 in my case), a zombie process is left behind for xdg-open. Setting wait=True avoids this, meaning that the docs for launch:
wait (bool) – Wait for the program to exit before returning. This only works if the launched program blocks. In particular, xdg-open on Linux does not block.are perhaps not fully accurate when it comes to WSL2.
As an aside, I believe this is an issue that has only arisen recently, as I have not noticed issues before, but it is difficult to know if it has arrived with any specific package upgrade or change to the WSL implementation.
To replicate:
From within a python shell in WSL2:
import click
click.launch("https://www.google.com")The site will open, in another window, run ps aux | grep [x]dg-open and you will see a zombie process. This will disappear of course when the parent process (the python shell) is closed, but remains until then.
Expected behaviour
There should be no zombie processes, regardless of whether the wait flag is passed or not.
Suggested solution
Add a check for WSL in src/click/_compat.py:
WSL = "microsoft-standard" in package.uname().releaseThen use this in src/click/_termui_impl.py to implicitly call Popen with wait() if running from WSL (without assigning it to a var, which I think may also keep the process open!
if WSL:
subprocess.Popen(["xdg-open", url]).wait()
else:
c = subprocess.Popen(["xdg-open", url])
if wait:
return c.wait()Failing that, if this is undesirable for any reason, then I think at least an amendment to the docs to indicate that wait=True should always be set when running within WSL in order to avoid zombie processes.
Environment:
- Python version: 3.9.9
- Click version: Tested on both 7.1.2 (where it was originally discovered), and on 8.0.3. Same on both.
- Current version of
xdg-open: snapd-xdg-open/focal-updates 2.51.1+20.04ubuntu2 amd64
Source: pallets/click