Аманда-самосвал глохнет в R-режиме, на чем он застрял?

У меня есть машина Debian x86 с несколькими ТБ дискового пространства, которую я использую для резервного копирования своего домашнего офиса. (Виртуальные ленты затем отправляются в Amazon Glacier, хотя эту часть можно было бы сделать лучше) Один или два раза в неделю, насколько я могу судить, явно не связаны с каким-либо конкретным хостом, все останавливается:

 4034 ?        Ss     0:03 /usr/sbin/cron
30836 ?        S      0:00  \_ /usr/sbin/CRON
30837 ?        Ss     0:00      \_ /bin/sh -c /usr/sbin/amdump sswdawson
30838 ?        S      0:00          \_ /usr/bin/perl /usr/sbin/amdump sswdawson
30840 ?        S      0:00              \_ /usr/lib/amanda/driver sswdawson
30841 ?        S      1:09                  \_ /usr/bin/perl /usr/lib/amanda/taper sswdawson
30842 ?        R    4327:45                  \_ dumper0 sswdawson
31028 ?        Z      1:48                  |   \_ [ssh] <defunct>
31029 ?        S      0:02                  |   \_ /bin/gzip --best
30843 ?        S      1:50                  \_ dumper1 sswdawson
30844 ?        S      0:00                  \_ dumper2 sswdawson
30958 ?        Z      0:00                  |   \_ [ssh] <defunct>
30845 ?        S      0:00                  \_ dumper3 sswdawson
30886 ?        Z      0:00                  |   \_ [ssh] <defunct>
31025 ?        S      0:21                  \_ chunker0 sswdawson

Я, кажется, должен убить -9 процесс. Этот процесс показывает, что он постоянно выполняет:

poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=12, events=POLLIN}], 3, 0) = 2 ([{fd=4, revents=POLLHUP}, {fd=5, revents=POLLIN}])
read(5, "\2\0\0\0\0\0\0\0", 16)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
read(4, "", 144)                        = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8

Процесс lsof -p показывает, что это несколько каналов:

dumper  30842 backup    4r  FIFO               0,10      0t0 174689 pipe
dumper  30842 backup    5u  0000               0,11        0   8482 anon_inode
dumper  30842 backup    6u   REG              253,9        0    542 /var/log/amanda/log.error/dooku0._.0.20180909102535.errout
dumper  30842 backup    7w  FIFO               0,10      0t0 177175 pipe
dumper  30842 backup    8w  FIFO               0,10      0t0 174690 pipe

Я предполагаю, что чтение происходит из несуществующего процесса ssh, а запись - во все еще активный процесс gzip:

istari-[~] mcr 10005 %sudo lsof -p 31029
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
gzip    31029 backup  cwd    DIR  253,4     4096 393224 /tmp/amanda
gzip    31029 backup  rtd    DIR  253,4     4096      2 /
gzip    31029 backup  txt    REG  253,4    98152 918298 /bin/gzip
gzip    31029 backup  mem    REG  253,4  1738176 918495 /lib/x86_64-linux-gnu/libc-2.19.so
gzip    31029 backup  mem    REG  253,4   140928 918491 /lib/x86_64-linux-gnu/ld-2.19.so
gzip    31029 backup    0r  FIFO   0,10      0t0 177175 pipe
gzip    31029 backup    1w   REG  253,4  1638400 658777 /etc/amanda/sswdawson/index/dooku0/_/20180909101001_0.gz.tmp
gzip    31029 backup    2w  FIFO   0,10      0t0 177176 pipe

Я бегу:

istari# amadmin version --version
amadmin-3.3.6

Если процесс действительно не функционирует, почему он все еще излучает несколько байтов. Есть ли способ, которым я могу проследить эти трубы и anon-трубы, чтобы увидеть, как они связаны? Что поддерживает процесс, когда он должен был умереть?

0 ответов

Другие вопросы по тегам