Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bash.exe -c "nohup winver.exe &" leaves init using 100% CPU on one core #12361

Open
1 of 2 tasks
dreamlayers opened this issue Dec 10, 2024 · 3 comments
Open
1 of 2 tasks

Comments

@dreamlayers
Copy link

Windows Version

Microsoft Windows [Version 10.0.19045.5131]

WSL Version

2.1.4.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

4.4.0-19041-Microsoft

Distro Version

Ubuntu 24.04.1 LTS

Other Software

No response

Repro Steps

If I open an ordinary Windows cmd prompt window (not WSL). There run bash.exe -c "nohup winver.exe &" or wsl.exe -e bash -c "nohup winver.exe &".

Expected Behavior

WSL should run temporarily, starting winver.exe and then closing.

Actual Behavior

After WSL exits, an init process remains, using 100% CPU on one core. Even after winver.exe is closed, that init process remains, endlessly wasting CPU time like that. Every time this is repeated, another init process like this is created, each wasting CPU time.

Other than this, everything seems fine. I am returned to the cmd prompt immediately, and winver remains running.

If the nohup is not used, or the & is not used, then this problem does not occur.

Workaround: Using bash.exe -c "winver.exe &" gives more reasonable behaviour. The first run leaves behind two init processes, but they do not waste CPU time, and repeating it does not create more lingering init processes. Even though nohup is not used, winver remains running, probably because SIGHUP doesn't affect ordinary Windows processes. Another alternative that doesn't cause problems is bash.exe -c "winver.exe & disown"

Diagnostic Logs

No response

Copy link

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@OneBlue
Copy link
Collaborator

OneBlue commented Dec 10, 2024

Thank you @dreamlayers. Interestingly I can't reproduce the issue. Could you share a coredump of the init process that's consuming CPU ?

@dreamlayers
Copy link
Author

Here is a core dump generated via gcore from WSL1: hanging_init_core.gz.

This was soon after booting into Windows. The first time I did bash.exe -c "nohup winver.exe &", winver didn't run at all, and init wasn't consuming CPU afterwards. I waited for CPU activity to fall to single digits and then tried again and reproduced this. It seems like there is some race condition when running an ordinary Windows program from WSL1 and then immediately exiting WSL1. When launching Windows programs that take a longer time to start up, I need a sleep 1 after the & to make them start successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants