30 Apr
2024
30 Apr
'24
2:45 a.m.
On Monday 29 April 2024 18:54:42 Steven D'Aprano via tde-users wrote:
That is pretty much what I suspected, that I had discovered a bug, but I
didn't really want to go through the steps of reporting it.
However ... in the interests of helping the TDE devs, and also for the
betterment of all humanity ... I will file a bug report, if somebody points
me in the right direction.
Bill
On Mon, Apr 29, 2024 at 03:39:33PM -0700, William
Morder via tde-users
wrote:
As for that
other zombie, the one generated when I start up tderandrtray:
that bothers me more, as its behavior makes no sense. When I quit or kill
tderandrtray, the zombie vanishes; when I start it up again, the zombie
is back.
That makes perfect sense.
A zombie is a process which has ended but remains in the OS's process
table. A zombie is not running, it does not use any CPU resources, only
a negligible amount of memory, and an entry in the process table.
https://www.baeldung.com/linux/clean-zombie-process
By default, most Linux systems have at least 32768 evailable slots in
the process table, so even in a rather busy system with thousands of
running processes, one or two zombies are unlikely to fill the table up.
https://unix.stackexchange.com/questions/586723/process-table-limit
Your observations suggest that there is a (hypothetical) bug in
tderandrtray:
- it launches a subprocess, which does its job and then either dies or
completes normally;
- but tderandrtray fails to call wait on the subprocess;
- which is how you get zombies.
Killing the parent, tderandrtray, should allow the OS to remove the
zombie, which is exactly what you are seeing.
https://unix.stackexchange.com/questions/74028/is-a-persistent-zombie-proce
ss-sign-of-a-bug