1

I sure wish I could kill the parents of these zombies (as seen below) and get on with life without rebooting. As I understand it, the unkillable D state is caused by an uninterruptable system call. In my case, it is likely related to a ZFS operation in the system that is the target of an rsync copy. I wonder if anyone can advise me about how to gain insight on why ZFS is hanging in my Ubuntu 17.04 box. Any new process that tries to access the zpool (and only this zpool) hangs now. Another zpool is operating OK.

FWIW, I suspect this started when I started a concurrent rsync to copy from the target to another zpool, but I wasn't present (I did: sleep 3600;rsync...). Too many balls to juggle for ZFSLINUX?

So what's a good way to gather diagnostic info for the upstream gurus?

root@face:~/Desktop# ps axl|grep rsync
5     0 22349     1  20   0  25676  2296 cv_wai D    ?          5:46 rsync --server -vlogDtpre.iLs --delete . /mirror
0     0 22517     1  20   0  23324  2952 cv_wai D    ?          0:00 rsync -av open /port/cosi
1     0 22518 22517  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25227     1  20   0  23816  3112 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25229 25227  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25447     1  20   0  23816  3120 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25449 25447  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25646     1  20   0  23816  3064 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25648 25646  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
0     0 25828 18113  20   0  14240   988 pipe_w S+   pts/28     0:00 grep --color=auto rsync
root@face:~/Desktop# kill -9 25447
root@face:~/Desktop# ps axl|grep rsync
5     0 22349     1  20   0  25676  2296 cv_wai D    ?          5:46 rsync --server -vlogDtpre.iLs --delete . /mirror
0     0 22517     1  20   0  23324  2952 cv_wai D    ?          0:00 rsync -av open /port/cosi
1     0 22518 22517  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25227     1  20   0  23816  3112 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25229 25227  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25447     1  20   0  23816  3120 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25449 25447  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
4     0 25646     1  20   0  23816  3064 cv_wai Ds   ?          0:00 rsync --server -vlogDtpre.iLs --delete . /mirror
1     0 25648 25646  20   0      0     0 -      Z    ?          0:00 [rsync] <defunct>
0     0 25887 18113  20   0  14240   992 pipe_w S+   pts/28     0:00 grep --color=auto rsync
  • 3
    IMO the rsync problem is an irrelevant distraction. the real problem is whatever's wrong with your zpool. btw, i routinely run multiple simultaneous rsyncs to the same zpool (nightly cron jobs to backup all hosts on my LAN) without a problem, so rsync is not the cause. start by checking your kernel logs. – cas Jul 22 '17 at 13:25
  • 1
    Oh, certainly, it is ZFS related, but probably not the root cause. New information indicates that the repeated ZFS failures are probably being caused by memory instability in this new machine. The syslog was showing exceptions with paging request failures. I continue to investigate by running memory diagnostics and shuffling RAM sticks. Thanks for the response. – Bill Michaelson Jul 23 '17 at 4:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.