[Решено] Transmission состояние процесса D

Привет. возникла проблема.
установил Transmission, настроил.
Через пару минут работы все закачки и раздачи останавливаются (что он успел скачать, на диск сохраняется), из клиента не возможно выйти и перезагрузить его.
Htop показывает следующее

остальные процессы (которые в состоянии S) успешно прибиваются при помощи killall, а тот, что в состоянии D не убиваетя.
И как следствие нельзя выключить или перезагрузить системник, только хардресерт кнопкой.
Пробовал transmission-cli (-ipv6) и transmission-gtk - ведут себя одинаково
файлопомойка на отдельном винте, права на директорию 777.
Помогите решить проблему.
dancerla2
в состоянии D
D это ожидание, а чего он ждет неизвестно.
Попробуйте из эмулятора терминала запустить transmission-gtk
и посмотреть вывод

На Гтк торрент еще неплохой deluge, можете его попробовать
pacman -S deluge
#запуск
deluge-gtk
dancerla2
тот, что в состоянии D не убиваетя
И не убъется. Это ожидание дисковой операции.
Почему у вас так - надо копать, возможно глубоко: винт, файловая система... хз.
Aivar
надо копать, возможно глубоко
Хороший случай для практики
Ошибки не исчезают с опытом - они просто умнеют
dancerla2, ради интереса, покажи выводы (редкий случай - не часто приходится проверить теорию на практике)
cat /proc/PID/wchan
grep N /usr/include/asm/unistd_64.h
sudo cat /proc/N/stack
где
PID - PID зависшего процесса
N - значение вывода sudo cat /proc/PID/syscall | awk '{print $1}'
Ошибки не исчезают с опытом - они просто умнеют
Aivar
dancerla2
тот, что в состоянии D не убиваетя
И не убъется. Это ожидание дисковой операции.
Почему у вас так - надо копать, возможно глубоко: винт, файловая система… хз.
Этот винт некоторое время назад "умер", падал в ro, потом перестал монтироваться.
Пробовал проверку фс делать, что то тогда исправилось, но потом раздел вообще пропал.
Я попробовал ddшкой занулить все, она посыпала ошибками после первых 3-5ГБ (рандомно, если несколько раз запустить, фото ниже)

Вообщем забил и убрал винт из fstab.
А тут вспомнил о нем, заново сделал раздел, отформатировал, решил, что все норм, он монтируется, но как выяснилось торрент виснет, и при выключении винт не может отмотироваться. только ресет кнопкой.
Вывод смарт
файлопомойка
для сравнения
SSD с системой
винт для мультимедиа папок пользователя
Не знаю, что думать, но всякие Pre-fail в выводе мне не нравятся,
Что это, винты помирают?
Вопрос не в тему, у этого форума есть тег [spoiler] или что то аналогичное для скрытия простыней текста?
vasek
dancerla2, ради интереса, покажи выводы (редкий случай - не часто приходится проверить теорию на практике)
[[email protected] ~]$ cat /proc/1315/wchan
0[[email protected] ~]$ sudo cat /proc/1315/syscall | awk '{print $1}'
[sudo] пароль для dmitrii:
18
[[email protected] ~]$ grep 18 /usr/include/asm/unistd_64.h
#define __NR_pwrite64 18
#define __NR_getresuid 118
#define __NR_nfsservctl 180
#define __NR_getpmsg 181
#define __NR_putpmsg 182
#define __NR_afs_syscall 183
#define __NR_tuxcall 184
#define __NR_security 185
#define __NR_gettid 186
#define __NR_readahead 187
#define __NR_setxattr 188
#define __NR_lsetxattr 189
#define __NR_set_tid_address 218
#define __NR_getrandom 318
[[email protected] ~]$ sudo cat /proc/18/stack
[<0>] smpboot_thread_fn+0x137/0x240
[<0>] kthread+0x113/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0xffffffffffffffff
[[email protected] ~]$ 
dancerla2
Не знаю, что думать, но всякие Pre-fail в выводе мне не нравятся,
Что это, винты помирают?
постоянно периодически натыкаюсь на такую фигню, причина - гавённые sata разъёмы, раз в 2-3 недели нужно продёргивать контакты, помогает только замена на качественный sata кабель, и то не гарантированно т.к. остаются разъёмы на винте и матери.
grayich
dancerla2
Не знаю, что думать, но всякие Pre-fail в выводе мне не нравятся,
Что это, винты помирают?
постоянно периодически натыкаюсь на такую фигню, причина - гавённые sata разъёмы, раз в 2-3 недели нужно продёргивать контакты, помогает только замена на качественный sata кабель, и то не гарантированно т.к. остаются разъёмы на винте и матери.
Было такое - часто имел подобные выводы о проблемах в прошлом году, как на последней картинке. Диск отсылал даже производителю, они не нашли проблем, перешили прошивку... У меня же снова начались те же проблемы. И вдруг решилось всё - сменил комп, другая плата и новый кабель. Вспомнил при этом, что один кабель SАТА (как раз на этом диске) не мог снять с разъёма платы, крепко зацепился почему-то. Видимо, пытаясь снять его, дёрганьем повредил. На новом месте никаких проблем. Я уже думал, что гарантийщики отписались, чтобы отделаться, оказалось, правда.
Поверхностный анализ показывает следующее
1. По выводам на команды.
Приложение находится в беспробудном сне - не ожидает никакого события, которое должно/может вывести его из состояния ожидания.
Приложение зависло на системном вызове pwrite(записывает максимум count байтов из буфера buf в файловый дескриптор fd, начиная со смещения offset) - и можно предположить, что проблема связана с HDD и либо железная либо программная.
2. По приведенным логам на изображении.
Из 4-х стантартизованных строк вывода сообщений ATA, отсутствует самая 1-ая, которая показывает состояние Error Handler и из которой обычно можно выудить информацию об ошибке. Видимо контроллер не смог обработать и вместо этой строки выдал сообщение
ata5.00: failed command: WRITE FPDMA QUEUED
Нужно гуглить по этому сообщению, но навскидку, насколько помню, это связано с ошибками связи между контроллером SATA и жестким диском. Кстати, на это же указывает и фраза ATA bus error (chip<->device bus error)
Вероятные причины
- проблема с драйвером контроллера
- кабель/шлейф
- источник питания (напряжение)

Но я бы попробовал отключить NCQ и посмотреть на поведение HDD
# echo 1 > /sys/block/sdX/device/queue_depth
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.