du виснет и не убивается даже с -9

https://habr.com/ru/articles/209446/

статья старая, но исключительно годная

если совсем лень читать, с потолка предположу 2 проблемы

1. слишком много (существенно больше миллиона) файлов
2. где-то ниже смонтирован nfs с параметром hard. или по крайней мере без параметра soft

но лучше всё же прочитать статью и пройти по шагам отладки

при этом, в директорию я зайти могу

а что при этом покажет

$ ls -ld .

покажет это:
drwx------ 2 root root 147456 июл 5 00:00 .
drwx------ 2 root root 90112 июл 4 23:56 .

(там 2 диры внутри и в одной 1573 файла, а в другой 841)
nfs-ов нету
есть виртуалка, из которой прокинуты 2 диры, но они на другом диске

статья 2014 года...

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет.

у меня там 4.19 (и то уже старое)
но какие-то базовые фишки потестю

Не так много

Аномальное поведение одной директории (комментарий) (и далее по треду)

что-то дичь какая-то с этим du...
он в состоянии D (беспробудный сон)
квантов процессора сожрал всего 1 (cat /proc/19177/status)
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 0

при этом, CPU жрёт всё это время (top -cbp 19177)
%Cpu(s): 16,5 us, 0,8 sy, 0,0 ni, 81,8 id, 0,0 wa, 0,0 hi, 0,8 si, 0,0 st

как это вообще понимать?!

strace посмотри

strace просто виснет
как и pstack

Не к запущеному du а ещё один сдеай под strace - увидишь сисколл на котором он зависнет.

«директория с письмами» - гыгы!

есть виртуалка, из которой прокинуты 2 диры

Вот с этих нюансов и надо начинать задавать вопрос в топике. Но от вас мы так и не услышали подробностей. Хуиз потерпевший(виртуалка)? куда он пошел(как прокинуты)?

дальше читай

• wchan
• syscall
• stack

syscall показывает тот же 262 (чтение свойств файла «new-fstat-at»)
какой-то файл на диске не даётся на чтение
но это было и так понятно
fsck запустить не могу, потому что сервер удалённый, а раздел рутовый и не могу его размонтировать
просто не припомню, чтобы kill -9 не смог убить процесс

да вот на этом и зависает:
newfstatat(5, «filename»,

вот прям в таком виде и виснет после запятой

Сделай stat этому файлу, наверно тоже зависнет.

завис

меня больше волнует, почему SMART показывает всё ок и чего ждать от диска теперь
он в продакшене

Ребутнись без этого раздела (или в read-only) и сделай ему fsck -f, Если зависший du будет мешать ребуту то sysrq+b или кнопкой.

раздел /, а сервак удалённый
не получится так

Смарт это не универсальное средство ловли всех проблем, он показывает только проблемы на стороне железа и только те которые успел заметить. А у тебя скорее всего файловая система немного побилась, уж не знаю почему. Были аварийные ребуты раньше?

ну кнопкой вырубали, бывало

Ну, других (нормальных) вариантов нет. Едь туда, или связывайся с теми кто сделает это, или проси kvm доступ.

Есть два плохих способа: 1) организуешь разделу аварийный remount-ro (как это сделать - отдельный вопрос), потом fsck, потом аварийный ребут (его можно и без физ. доступа сделать);

2) читами прописываешь разделу отсутствие журнала, затем делаешь аварийный ребут, и ОС сама запустит нужный fsck, но ты не увидишь его логов; потом надо назад включить журнал будет уже штатным способом.

Но если что-то пойдёт не так - всё равно придётся ехать/просить, так что лучше сразу этот вариант думай. Ну а пока просто не трогай этот файл.

rm тоже виснет :\

просто не припомню, чтобы kill -9 не смог убить процесс

Вы просто ещё очень молоды и на вашем жизненном пути не встречались зомби. :)

dmesg изучали?

Раньше можно заставить сделать проверку ФС при загрузке, если создать файл с нужным именем в корне, но может в вашем дистре этого уже нет. Если extfs, то можно через tune2fs установить max-mount-count в 1, при ребуте будет проверка. Но, не факт что автоматическая проверка ФС справится, она может захотеть задать вопрос.

В принципе, если остановить все службы, кроме sshd, то можно перемонтировать корень в readonly и чекать. Но, в вашем случае, наверно, нужно сначала сделать reboot через sysrq, штатный ребут может и зависнуть из-за этих зомби процессов.

А разговоры про удалённый сервер... А если бы накопитель посыпался или неудачно обновился glibc, сервер перестал загружаться, то что бы вы делали?

да было такое, неделю мучались, потом все равно ребутнули