LINUX.ORG.RU

Процесс завис на сбойной флешке

 kill -9,


0

1

Несколько раз сталкивался с этой проблемой, сегодня опять. На этот раз с телефоном (звонилка Philips за 700 рублей) в режиме флешки.

Если процесс читает или пишет со сбойного съёмного диска, он может намертво подвиснуть. После этого на него ничего не действует, кроме перезагрузки. kill, pkill, в том числе с ключами -f и -9, то же от рута, выдёргивание флешки — ничего не убивает этот процесс. umount тоже не работает.

Дополнение: poweroff на машине с 2 зависшими устройствами и 3 зависшими программами (mc и mc от пользователя и ls от рута) не смог выключить машину за 5 минут, пришлось жать выключатель.

Поиск в интернете показал, что этот процесс находится в состоянии «Uninterruptible sleep» («D» во 2-й колонке на ps -lA). Существуют ли в современном линуксе способы его прибить и отмонтировать флешку? Помимо ребута. Есть ли способы монтировать флешки так, чтобы их выдёргивание не вызывало проблем у остальной системы?

Ядро 4.4.6-gentoo.

Заранее спасибо.

P.S. Если телефон Philips E120 подключён по USB как накопитель, когда он заканчивает заряжаться, он с некоторой вероятностью вешает процесс чтения или записи.

★★★★★

Последнее исправление: question4 (всего исправлений: 1)

Это ошибка/недоработка в ядре, хотите, станьте кернел-хакером и разберитесь, какой модуль и где именно клинит.

mky ★★★★★
()

umount -l и дёргать. Файловой системе на устройстве не понравится, но оно тут и так виновато. После извлечения процесс должен получить ошибку от системного вызова, на котором был заблокирован.

anonymous
()
Ответ на: комментарий от anonymous

umount -l

Спасибо, директорию отпустило. Но процесс висит, и устройство /dev/sdc1, по-прежнему, присутствует. Хуже того, при повторном подключении накопителя к этому же гнезду, он его видит только как источник питания.

question4 ★★★★★
() автор топика
Ответ на: комментарий от mky

Это ошибка/недоработка в ядре, хотите, станьте кернел-хакером и разберитесь, какой модуль и где именно клинит.

В чём проблема? Вызов read() и вся цепочка вызовов для чтения с FAT должны уметь выставлять состояние TASK_KILLABLE ?

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

Существуют ли в современном линуксе способы его прибить и отмонтировать флешку?

Нет. TASK_UNITERRUPTIBLE невозможно убить, а мудак Хартман так сделал USB-интерфейс, что это состояние постоянно используется.

Спасибо, директорию отпустило

Не отпустило - просто ее не видно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

TASK_UNITERRUPTIBLE невозможно убить, а мудак Хартман так сделал USB-интерфейс, что это состояние постоянно используется.

А нельзя ли его сделать TASK_KILLABLE?

Не отпустило - просто ее не видно.

Если я примонтирую к той же /mnt/flash ту же флешку повторно, старый процесс мне мешать будет?

question4 ★★★★★
() автор топика
Последнее исправление: question4 (всего исправлений: 2)
Ответ на: комментарий от question4

TASK_UNITERRUPTIBLE невозможно убить, а мудак Хартман так сделал USB-интерфейс, что это состояние постоянно используется.

А нельзя ли его сделать TASK_KILLABLE?

Без модификации ядра - думаю, нет.

Если я примонтирую к той же /mnt/flash ту же флешку повторно, старый процесс мне мешать будет?

Процесс - нет. Но, подозреваю, сколько раз ты вставишь дохлую флешку, столько мертвых процессов и занятых инодов у тебя будет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Без модификации ядра - думаю, нет.

Об этом и спрашивал — не удосужился ли кто позволить прерывать зависшие вызовы, когда вызывающая программа, всё равно, убивается.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

Всё несколько сложнее, чем просто «удосужился». Потому что удосужились давно, но никто не пользуется возможностью.

tailgunner ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Не знаю. Но это старая юниксовая родовая травма, так что может быть.

tailgunner ★★★★★
()
Ответ на: комментарий от question4

Не знаю насчёт TASK_KILLABLE, но драйвер устройства должен определять, что с устройством проблемы, допустим, по таймауту выполнения операции, и возвращать ошибку, а все выше должны быть готовы эту ошибку обработать.

mky ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

А в *BSD эта проблема есть?

https://lwn.net/Articles/288056/

Unix tradition (and thus almost all applications) believe file store writes to be non signal interruptible. It would not be safe or practical to change that guarantee.

В данном случае происходит невосстановимый аппаратный сбой при чтении, поэтому результат в любом случае будет мусорным, поэтому имеет смысл разрешить процесс убить. В Линуксе для некоторых операций разрешили, начиная с версии 2.6.25 лет 9 назад, для некоторых — ещё нет. Я надеялся хотя бы узнать про опции монтирования, которые позволят прибивать такие процессы в будущем.

Подозреваю, что в BSD не лучше.

question4 ★★★★★
() автор топика
Последнее исправление: question4 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.