AMP
AMP copied to clipboard
Zombie processes being left after stopping generic instances using Xvfb/Wine
Bug Report
System Information
- Ubuntu 20.04.4 (in LXD container)
- 2.3.3.4
- Mainline
I confirm:
- [x] that I have searched for an existing bug report for this issue.
- [x] that I am using the latest available version of AMP.
- [x] that my operating system is up-to-date.
Symptoms
When running generic instances in Docker that use Xvfb and Wine, stopping the server (as opposed to the instance) leaves zombie processes.
For example, Carrier Command 2. First screenshot is while the server is running, second is after it is stopped:
Similarly, the screenshot below is after stopping an Empyrion Galactic Survival server:
Query whether the situation is related to how AMP stops the server process and Xvfb process?
I always notice in the console the following after stopping the server (using OS_CLOSE):
X connection to :99 broken (explicit kill or server shutdown).
It seems that the Xvfb process might be stopped before, or too soon after, the server process is stopped, and hence it thinks the virtual screen is broken. Possibly this causes the shutdown process not to occur properly? If so, perhaps the Xvfb process shutdown can be delayed instead? Otherwise, perhaps the shutdown is not picking up all the related Wine processes?
Reproduction
Create instances as per above in Docker and then stop the servers.
And just for completeness, this is not an issue associated with the host being a LXD container. I get the same issue when running AMP on an AWS VPS.
Is the child monitor process set in the configuration in the same way that the V Rising configuration does it?
It's monitoring the correct process (wine rather than wine64 in these cases). Verified from debug logging.
Actually to clarify - it's wine in the case of CC2, and wine64 in the case of Empyrion
And if you stop just that process with a sigterm
in htop does that leave you with a zombie process or does it all end?
If htop is left open, the zombies are there (as well as new processes given AMP restarts the server). If htop is quit then re-opened, the zombies are gone
OK, so maybe this is just a htop display issue. If I stop the server normally in AMP, the zombies show. If I then quit htop and open it again, they are gone. If I don't have htop open at the time that the server is stopped, but then open htop, the zombies are not there
Are they there if you aren't in tree view though? Wondering if they don't show after a refresh because they lose their tree when zombies.
Just toggle with "t"? Not there
Sorry, there are still there if htop is already open when the server is stopped. Tree mode or not
But one htop is quit, they disappear when htop is opened again
Hmm, ps though shows a bunch of zombie wine processes
Putting them here for completeness:
amp 61066 0.0 0.0 0 0 ? Zs 22:47 0:13 [wineserver64] <defunct>
amp 61068 0.0 0.0 0 0 ? Z 22:47 0:00 [wineboot.exe] <defunct>
amp 61070 0.0 0.0 0 0 ? Z 22:47 0:00 [winemenubuilder] <defunct>
amp 61072 0.0 0.0 0 0 ? Zs 22:47 0:00 [services.exe] <defunct>
amp 61075 0.0 0.0 0 0 ? Z 22:47 0:00 [plugplay.exe] <defunct>
amp 61082 0.0 0.0 0 0 ? Z 22:47 0:00 [winedevice.exe] <defunct>
amp 61084 0.0 0.0 0 0 ? Z 22:47 0:00 [explorer.exe] <defunct>
amp 61093 0.0 0.0 0 0 ? Z 22:47 0:00 [winedevice.exe] <defunct>
amp 61117 0.0 0.0 0 0 ? Z 22:47 0:00 [winedbg] <defunct>
These are what remains after the server is stopped (but the instance is still running), even if not shown in htop.
Gotta think it is something to do with Xvfb being killed before all the wine processes are.
Something is really not right with the child process monitoring. Now with the latest Core Keeper template, only the Xvfb screen is stopped (creating X errors), and the server process is then only killed after the stop timeout, leaving a zombie process
This is still an issue on the latest AMP release.
What does the actual process tree look like?
Do the screenshots in the first post give what you need?
Addressed in 2.4.
Zombie processes are still left under 2.4.0.4, according to ps
. Tested with Conan this time