On Tuesday 23 April 2024 10:30:47 you wrote:
On one occasion, when I tried to kill dozens of zombie entries marked only w,
What marked these 'w' ? My `ps' man page says there is no such status. There was 'W' in the 2.6 kernel series, but I assume your system isn't that archaic. (Or is it?)
Hi Jim!
My machine is fairly new, only a couple years old, and I am running Devuan Daedalus, upgraded within the last month.
Here are some snips from top. I am only showing lines that relate to zombies or those mysterious processes with the label w. (For security reasons, I prefer not to show everything all at once about my system; such as, e.g., my user name.)
Please see attachments.
As you can see, I only have one zombie at present -- didn't try to track down what processes are involved -- but at times there have been as many as dozens. They seem to come in dozens or half-dozens, by the way, for reasons unknown to me: above a certain number, they always seem to come in multiples of 6 or 12, like 24, 36, 42. When it gets to be a couple dozen zombies, this irks me, and that's when I want to call in the zombie-killing experts.
No, I don't think it's "good" for so many zombies to persist after their parents have quit running, but I also don't notice that my system runs any worse. When I thought that I had identified one of my zombies as one of those mysterious w processes, and tried to kill that, that's when I shut down my session and lost my work; which, obviously, was worse that putting up with zombies.
It seems to me that the mysterious w is not any one process, but rather a kind of process that has become a zombie. Otherwise, there could not be, as sometimes happens, half a dozen processes named w.
As for the age of my machine or system: the nature of Devuan in spirit is more deliberately set against newfangled shiny toys, and tends to rely on the more reliable stone tools used the hardcore caveman geeks.
Bill
P.S. Apologies if I sent some duplicate emails. For some reason, my response to Jim, with attachments, did not go through. Please consider this one to be the authorized version ... if it goes through.
William Morder via tde-users wrote:
It seems to me that the mysterious w is not any one process, but rather a kind of process that has become a zombie. Otherwise, there could not be, as sometimes happens, half a dozen processes named w.
you find a zombie with ps auxwww | grep 'Z' and it is usually <defunct>
A process in Linux can have one of the following states:
D = uninterruptible sleep I = idle R = running S = sleeping T = stopped by job control signal t = stopped by debugger during trace Z = zombie
look here https://itsfoss.com/kill-zombie-process-linux/
$ ps auxwww | grep 'Z' USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND emanoil 719868 0.0 0.0 0 0 ? Z 20:22 0:00 [firefox-bin] <defunct> emanoil 732279 0.0 0.0 6332 2192 pts/3 S+ 22:49 0:00 grep Z
On Tuesday 23 April 2024 13:53:58 deloptes via tde-users wrote:
William Morder via tde-users wrote:
you find a zombie with ps auxwww | grep 'Z' and it is usually <defunct>
A process in Linux can have one of the following states:
D = uninterruptible sleep I = idle R = running S = sleeping T = stopped by job control signal t = stopped by debugger during trace Z = zombielook here https://itsfoss.com/kill-zombie-process-linux/
$ ps auxwww | grep 'Z' USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND emanoil 719868 0.0 0.0 0 0 ? Z 20:22 0:00 [firefox-bin] <defunct> emanoil 732279 0.0 0.0 6332 2192 pts/3 S+ 22:49 0:00 grep Z
Yes, thank you. I have searched online for how to get rid of zombies, but there is no simple or quick way of killing all processes with that status of Z or <defunct>. I must go through my processes, find them individually, find their parent processes, and so on.
It seems to me that if a system can identify processes with that status, then it should be possible to create a command that can find and kill all processes listed with the status of Z or <defunct>. Why this cannot be, I don't know, but at present the only way I know to kill zombies is one-at-a-time.
The problem here is time. I don't have time to do this, and it does not seem to be causing any harm to my system.
I don't like to see zombies, especially not when they pile up to dozens of them, but it is more of an aesthetic annoyance rather than an urgent problem.
Maybe over this weekend I can do some zombie hunting. I do think that it would be useful to know if it is, for example, the cause is the same process or processes. It is possible that I am doing something that results in these processes leaving zombies behind.
Bill
Hello, What means "Defunct" (Zombie) ? Thanks. André
On Wednesday 24 April 2024 17:41:11 William Morder via tde-users wrote:
A process in Linux can have one of the following states: D = uninterruptible sleep I = idle R = running S = sleeping T = stopped by job control signal t = stopped by debugger during trace Z = zombie look here https://itsfoss.com/kill-zombie-process-linux/
On Wednesday 24 April 2024 09:04:39 you wrote:
Hello, What means "Defunct" (Zombie) ? Thanks. Andr�
On Wednesday 24 April 2024 17:41:11 William Morder via tde-users wrote:
A process in Linux can have one of the following states: D = uninterruptible sleep I = idle R = running S = sleeping T = stopped by job control signal t = stopped by debugger during trace Z = zombie look here https://itsfoss.com/kill-zombie-process-linux/
That is just a kind of "ghost" (so to speak), traces of a process that is no longer actually running.
Bill
William Morder via tde-users wrote:
That is just a kind of "ghost" (so to speak), traces of a process that is no longer actually running.
In my case the parent firefox process was still running. The child process was killed because of "high quality" developers of web pages are producing such content that overloads the system and oom killer kicks in. The stupid thing is, it causes the PC to consume also more power untill it decides to die or be killed.
On Thursday 25 April 2024 22:37:44 deloptes via tde-users wrote:
William Morder via tde-users wrote:
That is just a kind of "ghost" (so to speak), traces of a process that is no longer actually running.
In my case the parent firefox process was still running. The child process was killed because of "high quality" developers of web pages are producing such content that overloads the system and oom killer kicks in. The stupid thing is, it causes the PC to consume also more power untill it decides to die or be killed.
In my own case, recent developments have provided some new information. Last night I went to sleep and forgot to take the machine offline, and in the morning, I found that I had been disconnected. Internet here has again been iffy, off and on, but sometimes I get knocked offline for unknown reasons.
Now that I think about it, when I do have crowds of zombies, it usually seems to happen when I have gone offline, or been knocked offline, rather than shutting down certain internet programs, notably tor and privoxy. (I use tork-trinity to manage my proxies.)
I had to restart my proxy, then I used iwconfig and ifconfig to restart my connection. I noticed that top showed 17 zombies.
So I said, let's see. As one can see from the output below, most of these zombies are indeed root processes named w, whatever that means here.
No (if readers are wondering), I have not yet tried to trace these PIDs to discover exactly what are these processes; but at least I know that those mysterious w processes indeed often are the zombies, and that they are owned by root.
Bill
ps auxwww | grep 'Z'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1107 0.0 0.0 0 0 ? Z Apr23 1:43 [w] <defunct> root 2471 0.0 0.0 0 0 ? Z Apr23 2:01 [w] <defunct> <user> 3782 0.0 0.0 0 0 ? Z Apr21 0:00 [sh] <defunct> root 4779 0.0 0.0 0 0 ? Z Apr21 3:25 [w] <defunct> root 4863 0.0 0.0 0 0 ? Z Apr23 1:36 [w] <defunct> root 8831 0.0 0.0 0 0 ? Z Apr24 1:00 [w] <defunct> root 10333 0.0 0.0 0 0 ? Z Apr24 1:30 [w] <defunct> root 10486 0.0 0.0 0 0 ? Z Apr22 2:56 [w] <defunct> root 11969 0.0 0.0 0 0 ? Z Apr24 1:10 [w] <defunct> root 15604 0.0 0.0 0 0 ? Z Apr24 0:59 [w] <defunct> root 16754 0.0 0.0 0 0 ? Z Apr22 2:22 [w] <defunct> root 17309 0.0 0.0 0 0 ? Z Apr22 2:14 [w] <defunct> root 21189 0.0 0.0 0 0 ? Z Apr24 1:03 [w] <defunct> root 21852 0.0 0.0 0 0 ? Z Apr22 2:50 [w] <defunct> root 23849 0.0 0.0 0 0 ? Z Apr23 2:13 [w] <defunct> <user> 27727 0.0 0.0 1606224 928 ? Ssl Apr23 0:20 clamd -c /home/<user>/klammailkIZTym root 29096 0.0 0.0 0 0 ? Z Apr21 3:22 [w] <defunct> root 32585 0.0 0.0 0 0 ? Z Apr25 0:35 [w] <defunct>
On Fri April 26 2024 06:52:08 William Morder via tde-users wrote: <snip>
I had to restart my proxy, then I used iwconfig and ifconfig to restart my connection. I noticed that top showed 17 zombies.
So I said, let's see. As one can see from the output below, most of these zombies are indeed root processes named w, whatever that means here.
No (if readers are wondering), I have not yet tried to trace these PIDs to discover exactly what are these processes; but at least I know that those mysterious w processes indeed often are the zombies, and that they are owned by root.
<snip>
If I found unexpected things happening on a system I would be worried about the possibility of malware.
If I found an unexpected zombie with pid 12345 I would immediately do "file /proc/12345/exe" and proceed to investigate from there.
--Mike
William Morder via tde-users wrote:
So I said, let's see. As one can see from the output below, most of these zombies are indeed root processes named w, whatever that means here.
"w" is the name of the program that was executed
Did you write a program called w?
obviously this is wrong and I am not aware of any program called "w"
On Fri, Apr 26, 2024 at 09:15:46PM +0200, deloptes via tde-users wrote:
William Morder via tde-users wrote:
So I said, let's see. As one can see from the output below, most of these zombies are indeed root processes named w, whatever that means here.
"w" is the name of the program that was executed
Did you write a program called w?
obviously this is wrong and I am not aware of any program called "w"
w is a standard Unix/Linux utility.
https://en.wikipedia.org/wiki/W_(Unix)
On Friday 26 April 2024 20:41:23 Steven D'Aprano via tde-users wrote:
w is a standard Unix/Linux utility.
Okay, so thanks to all who have participated in this group effort to rid my system of zombies.
Last night, my zombies had multiplied to 17. When I did some searching for those processes, I found that all but one (for Kmail) were named w and owned by root.
The more I thought about this, the more it bothers me. For one thing, I don't run much of anything as root if I can help it. I sometimes open Konqueror as root to do something, but then I close it; I sometimes perform some admin tasks in a shell, but then I close out the root session. If these are system processes, then of course that is different, but why so many, and all named w? The function of W itself, described in the manpages, is: "Show who is logged on and what they are doing."
Well, I can find only 3 users in my system, myself, root, and another called message+; other than the three of us, there ought to be nobody else hanging out here.
Then I searched for these zombies by PID, then tried to remove them with kill -9 <PID #> ... and nothing happened. According to top, all 17 were still enjoying their undead life, and ignored my commands to go away.
A little searching discovered that at least some of these processes named w had to do with wicd. The reason for this, now it is clear, is that I was having network issues a few weeks ago (Nik and others will recall), and I installed wicd to see if I could use that to get my connection working again. Okay, so there were some unnecessary packages in my system. I purged everything wicd; that ought to get rid of zombies.
When I rebooted and went through my usual startup routines, I ended up with top showing 1 zombie, even though I have not as yet even gone online. (I control my online/offline status using iwconfig and ifconfig, so that when I take my machine offline, I can be sure that it is really offline, and of course I never permit any kind of autoconnect.)
I searched for this sole zombie: ps -el | grep 'Z' F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 Z 1000 3731 3727 0 80 0 - 0 - ? 00:00:00 sh As you can see, in this case it is a shell owned by myself, user 1000. When I search for its parent, that turns out to be: <user> 3727 0.2 0.5 72532 33520 ? S 10:05 0:00 tderandrtray -session 1013f12f150140000168161448200000028290036_1714235508_309905
Now why would tderandrtray be leaving zombies behind? For one thing, I rarely touch it; tderandrtray just sits there for ages on end without my ever touching it, so I have to wonder what it's doing at all, and why it would leave zombies behind.
Just now, as an experiment, I tried to kill tderandrtray, kill -9 3727 and presto! tderandrtray disappears from my systray, and the zombie also magically disappears from top. So then I restart tderandrtray, and poof! the sole zombie has instantly returned.
Just to be sure, I repeated this experiment a couple times, and the result is always the same. Somehow, tderandrtray, as soon as it is enabled, creates a zombie. The zombie is named sh, a shell process owned by user 1000, myself.
So in this case, at least, I believe that I have tracked down the most persistent of my zombies. I don't know if it's the only one related to tderandrtray, or if those w zombies running as root are somehow related, but at least there is one pretty clear result.
If anybody can make any sense of this, please feel free to enlighten us.
Bill
On Sat April 27 2024 10:44:36 William Morder via tde-users wrote:
Then I searched for these zombies by PID, then tried to remove them with kill -9 <PID #> ... and nothing happened. According to top, all 17 were still enjoying their undead life, and ignored my commands to go away.
Zombies are already dead. Killing them does nothing. They will remain zombies until one of three events:
(1) linux shutdown (2) parent collects them (3) parent dies
When the parent dies they are collected by pid 1 instead.
On Saturday 27 April 2024 11:14:36 Mike Bird via tde-users wrote:
On Sat April 27 2024 10:44:36 William Morder via tde-users wrote:
Then I searched for these zombies by PID, then tried to remove them with kill -9 <PID #> ... and nothing happened. According to top, all 17 were still enjoying their undead life, and ignored my commands to go away.
Zombies are already dead. Killing them does nothing. They will remain zombies until one of three events:
(1) linux shutdown (2) parent collects them (3) parent dies
When the parent dies they are collected by pid 1 instead.
Yes, as demonstrated by killing tderandrtray, which makes my current zombie go away, but doesn't explain those others, all named w and owned by root.
I did try finding the parent of those w processes, but when I searched, the processes didn't even come up in the list of zombies when I ran the command ps -el | grep 'Z'
It may be that those unused packages of wicd were causing the others. I will have to wait to find out the answer to that.
Bill
Anno domini 2024 Sat, 27 Apr 10:44:36 -0700 William Morder via tde-users scripsit:
[...] s one pretty clear result.
If anybody can make any sense of this, please feel free to enlighten us.
For what it's worth: today I purged network-manager and replaced it by connman + cmst. My networkmanager-related problems (not finding networks, not connecting ...) are gon now. That is, I still have dropping connections etc. but now I can detect if I got an incomplet network configuration and restart the connection if needed - and that takes seconds, not tenths of minutes.
As for the "w"-zombie: it might be a corrupt library. You can try this to check if the checksums match:
dpkg -l | awk {'print $2'} | xargs | debsums | grep -v 'OK'
... but as you live in the land-of-the-free™ I'd also run a check for a rootkit, just in case you had a visitor ...
Nik
Bill
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
On Saturday 27 April 2024 11:27:02 Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Sat, 27 Apr 10:44:36 -0700
For what it's worth: today I purged network-manager and replaced it by connman + cmst. My networkmanager-related problems (not finding networks, not connecting ...) are gon now. That is, I still have dropping connections etc. but now I can detect if I got an incomplet network configuration and restart the connection if needed - and that takes seconds, not tenths of minutes.
As for the "w"-zombie: it might be a corrupt library. You can try this to check if the checksums match:
dpkg -l | awk {'print $2'} | xargs | debsums | grep -v 'OK'
... but as you live in the land-of-the-free™ I'd also run a check for a rootkit, just in case you had a visitor ...
Nik
Well, I thought I would give those packages a try, so I installed connman, cmst and a dependency, ofono. I like the look of it, and it does seem to be useful as a backup plan, if my connection is giving me problems, and I want to do some testing and troubleshooting, trying to find out the source of the problem.
In this case, however, as soon as I installed these packages, I could neither send nor receive emails. No other internet programs seem to have been affected, so far as I can tell, though I did not search too far. My browser still works the same, my internet radio kept working throughout, except when I restarted the connection. So it appears that these packages at least have some conflict. I did not uninstall tdenetworkmanager, but I don't think that I am using the gnome networkmanager itself, unless it's hiding somewhere in the background. When I do a fresh system installation, I am used to seeing both the gnome networkmanager and tdenetworkmanager both in the systray. After I finish the setup of my system (which usually involves getting rid of unnecessary programs, especially KDE Plasma or Gnome packages, if they somehow creep in.
I tried restarting the connection, etc.: I did not go so far as to reboot, as I have a few other things to do before the sun goes down.
Then I purged these packages, and again, email is back and functioning normally. So I may hang onto this connman and its helpers, just for backup, but for now I think I'll just stick with the tdenetworkmanager.
I will try out some of those other suggestions later today, after I spend a few hours outdoors.
Bill
Steven D'Aprano via tde-users wrote:
w is a standard Unix/Linux utility.
Indeed thanks for the link
On Sunday 28 April 2024 02:24:58 deloptes via tde-users wrote:
Steven D'Aprano via tde-users wrote:
w is a standard Unix/Linux utility.
Indeed thanks for the link
Just to report that my system appears to be rid of zombies. At present top has shown no zombies for at least 2-3 days.
Ever since I purged those unused packages of wicd from my system, that seems to have got rid of the mysterious w in root. I don't believe that I ever ran wicd as root, nor had I even started it up for the past few months. But that's the only suspect that seems to fit.
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.
For my everyday habits, this doesn't much affect me. I can just make sure that tderandrtray doesn't start up automatically with boot. If I recall, I was fiddling with screen size and power settings (sleep, hibernate, etc.), so I had set it to start with boot until I got those settings how I wanted, then forgot to unset it afterwards.
Thanks to all for their help and suggestions. I hope that my zombie hunting days are done, and I can move on to hunting more interesting quarry.
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-proces...
On Monday 29 April 2024 18:54:42 Steven D'Aprano via tde-users wrote:
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
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 2024-04-29 21:45:02 William Morder via tde-users wrote:
On Monday 29 April 2024 18:54:42 Steven D'Aprano via tde-users wrote:
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.
---%<---
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-pro ce ss-sign-of-a-bug
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
https://wiki.trinitydesktop.org/TDE_Gitea_Workspace
Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64) Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.1.1 tde-config: 1.0
On Monday 29 April 2024 20:07:05 J Leslie Turriff via tde-users wrote:
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-p ro ce ss-sign-of-a-bug
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.
https://wiki.trinitydesktop.org/TDE_Gitea_Workspace
Leslie
Thank you, will try to do that over the weekend.
It seems that there have been other issues with tderandrtray, but nothing that fits this description of its behavior, nothing about it leaving behind zombies.
Bill
I'm sorry if I makea blunder, I come late, not really followed the subject,
To kill a rebellious process, I type in root : kill -9 <process number>
André
On Wed April 24 2024 09:04:39 ajh-valmer via tde-users wrote:
What means "Defunct" (Zombie) ?
A zombie is a process that has died - exited or crashed - but it's parent process has not yet collected the exit code or termination reason using one of the 'wait' syscalls.
Usually this is due to a bug in the parent process.
On Wednesday 24 April 2024 19:06:51 Mike Bird via tde-users wrote:
On Wed April 24 2024 09:04:39 ajh-valmer via tde-users wrote:
What means "Defunct" (Zombie) ?
A zombie is a process that has died - exited or crashed - but it's parent process has not yet collected the exit code or termination reason using one of the 'wait' syscalls. Usually this is due to a bug in the parent process.
Thank you Mike.
André
On Wednesday 24 April 2024 19:06:51 Mike Bird via tde-users wrote:
On Wed April 24 2024 09:04:39 ajh-valmer via tde-users wrote:
What means "Defunct" (Zombie) ?
A zombie is a process that has died - exited or crashed - but it's parent process has not yet collected the exit code or termination reason using one of the 'wait' syscalls. Usually this is due to a bug in the parent process.
Thank you Mike.
André
Am Dienstag, 23. April 2024 schrieb William Morder via tde-users:
It seems to me that the mysterious w is not any one process, but rather a kind of process that has become a zombie. Otherwise, there could not be, as sometimes happens, half a dozen processes named w.
$ man w
…may help to find out.
Cheers, Stefan
-
ajh-valmer -
deloptes -
Dr. Nikolaus Klepp -
J Leslie Turriff -
Mike Bird -
Stefan Krusche -
Steven D'Aprano -
William Morder