zombie processes

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • zombie processes

      Checking the processes in the dashboard section I found (new?, since last omv4 update ?) 2 zombie processes:

      top - 20:37:08 up 1:34, 0 users, load average: 0.01, 0.02, 0.05
      Tasks: 163 total, 1 running, 160 sleeping, 0 stopped, 2 zombie
      %Cpu(s): 1.7 us, 0.6 sy, 0.0 ni, 97.3 id, 0.3 wa, 0.0 hi, 0.1 si, 0.0 st
      KiB Mem : 7828888 total, 2864172 free, 366204 used, 4598512 buff/cache
      KiB Swap: 15656956 total, 15656956 free, 0 used. 7131872 avail Mem

      ps aux | grep 'Z'
      USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
      root 14641 0.0 0.0 0 0 ? Zs 20:41 0:00 [mountpoint] <defunct>
      root 14642 0.0 0.0 0 0 ? Zs 20:41 0:00 [mountpoint] <defunct>
      root 14647 0.0 0.0 12788 976 pts/0 S+ 20:41 0:00 grep Z

      checking some times later

      ps aux | grep 'Z'
      USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
      root 14778 0.0 0.0 0 0 ? Zs 20:43 0:00 [mountpoint] <defunct>
      root 14779 0.0 0.0 0 0 ? Zs 20:43 0:00 [mountpoint] <defunct>
      root 14782 0.0 0.0 12788 976 pts/0 S+ 20:43 0:00 grep Z

      I've the same processes with other PID ?
    • Hi,

      I am an absolute n00b in Linux, Server, OMV, so please keep that in mind.

      I have the same Zombie-problem ... :( I think the "new PID" is not the problem,
      and "normal", but the root of all evil is another point.

      It seems to be, that the zombie-process/es end/s and then revive/s. then he gets a
      new PID assigned. The same thing would happen if you kill the zombie with

      kill 14778

      When the Z wont end and comes back, it gets a new PID (from father process!?).

      So it make no sense to kill the process, nor to kill the father process. This zombie
      keeps coming back. (in my case) The question we now have to ask ourselves is:

      What causes this MOUNTPOINT error / zombie? ?(

      Does anyone else have zombie processes related to MOUNT POINT?
      Does anyone have an answer for that?
    • Same here... 2 zombies processes

      Source Code

      1. root@omvglbvprd1:~# ps aux |grep 'Z'
      2. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
      3. root 15366 0.0 0.0 0 0 ? Zs 10:49 0:00 [mountpoint] <defunct>
      4. root 15367 0.0 0.0 0 0 ? Zs 10:49 0:00 [mountpoint] <defunct>
      5. root 15373 0.0 0.0 12788 1000 pts/0 S+ 10:49 0:00 grep Z
      Lian Li PC-V354 with Be Quiet fans | Gigabyte GA-G33M-DS2R | Intel E8400@3,6Ghz | 6GB DDR2 RAM
      1x500MB SSD for System/Backup | 7x2To HDD with ZFS RAIDz2 for Datas/Snapshots
      Powered by OMV v4.1.7 / Kernel 4.16.x / ZFS 0.7.9
    • sbocquet wrote:

      2 zombies processes
      So what? :)

      Ignoring them is the most simple way to deal with those processes especially since you can clearly read above how much impact they have on your system: exactly none (no memory wasted, just some entries in the process table that do not hurt)

      kerneltalks.com/howto/everything-need-know-zombie-process/

      If you want to investigate you would need to check PPID (parent process ID --> 'ps -eaf' and there 3rd column) to get an idea which process forked them (maybe just to realize that these processes have already quit). But the best way to deal with zombies is to learn that they're harmless if it's just a few and ignore them.
    • Hi tkaiser,

      I already done my research but haven't had the time to post here ;)

      Source Code

      1. root 1077 1 0 mars19 ? 00:00:11 /usr/bin/monit -c /etc/monit/monitrc
      2. ...
      3. root 20316 1077 0 11:42 ? 00:00:00 [mountpoint] <defunct>
      4. root 20317 1077 0 11:42 ? 00:00:00 [mountpoint] <defunct>
      5. root 20318 1077 0 11:42 ? 00:00:00 [mountpoint] <defunct>
      And here is the answer ;)
      Lian Li PC-V354 with Be Quiet fans | Gigabyte GA-G33M-DS2R | Intel E8400@3,6Ghz | 6GB DDR2 RAM
      1x500MB SSD for System/Backup | 7x2To HDD with ZFS RAIDz2 for Datas/Snapshots
      Powered by OMV v4.1.7 / Kernel 4.16.x / ZFS 0.7.9
    • sbocquet wrote:

      And here is the answer
      And since these zombies die pretty fast (look at your timestamps) it's just the result of monit calling '/bin/mountpoint' to get a clue which mountpoints or directories below /srv or /media belong to which block device (to graph disk utilization or whatever). They come and go most probably every minute or even seconds and are harmless :)

      Being a former heavy Solaris and still macOS user I love execsnoop.
    • Users Online 1

      1 Guest