Re: CD/DVD ROM eject: решение (или грабли?) вместо ivman
On 2006.03.01 at 01:40:38 +0300, Mikhail Ramendik wrote:
> > Здесь по крайней мере вызывается umount, пусть на уже вытащенный диск.
>
> Однако если хоть один процесс его держит, umount, если я правильно понимаю,
> просто не сработает :( А если не держит - так через таймаут (скажем, 3
> секунды) autofs тоже сделает размонтирование.
Насколько я понимаю, если файловая система уже недоступна, то ядро в
этом случае ведет себя немножко по-другому. Опять же ключик -f у umount
есть.
> > А по хорошему, по событию eject надо запускать fuser -m и прибивать все
> > процессы, использующие данную fs
>
> А вот этого я бы точно не делал. Зачем убивать файломенеджеры и шеллы, которые
> в этот момент смотрят на диск? Они ведь и так отнюдь не падают. Ради редких
> падающих/виснущих процессов убивать все?
Затем что если ты вытаскиваешь диск, то shell у которого CWD на этом диске
тебе уже не нужен. shell-ы это вообще расходный материал - для каждого
скрипта новая копия запускается.
А если у тебя есть файлменеджер, который держит директорию на съемном
носителе, и не отрабатывает корректно сигнал, то такой файлменеджер
убивать надо не сигналом а aptitude remove.
Собственно есть две ситуации:
1. Мелкая (в стиле unix-way) программа, которая была запущена специально
для работы с данными на этом диске. А потом просто пользователь забыл её
закрыть. Тогда прибивание программы по событию вытаскивания диска -
нормальное явление. Юзер не закрыл - система для него закроет.
2. Программа, которую убивать вообще-то жалко, но из-за того что
программист головой не подумал, она не отпускает диск вовремя. В этом
случае посылка сигнала делает тайный глюк (который имеет шансы
проявиться, если вдруг программа обратится к неотпущенному ресурсу)
явным. Нечто вроде electric fence, non-executable stack и прочих
подобных средств отладки и защиты.
В данном случае падение программы при вытаскивании диска делает просто
более заметным факт, что эта программа с диском неаккуратно обращается.
И, следовательно, должна быть либо исправлена, либо заменена на более
правильную.
> Мне кажется, что правильно было бы сделать некую proxy file system (на fuse,
> вероятно, чтобы в ядро не лезть лишний раз), которая будет работать через
> обычную FS, но корректно отрабатывать её пропадание в любой момент (т.е. не
> зависать, а fail'иться). Однако я такое вряд ли в состоянии написать :( А
Лично я не понимаю какая нафиг разница между fail-ящимся системным
вызовом и прилетающим сигналом. И то, и другое может быть программой
обработано. И то, и другое по умолчанию приводит к падению программы.
В данном случае реализация особой ситуации посредством посылки сигнала
обходится намного проще чем реализация её посредством возврата ошибки из
системного вызова.
> Я бы рад сменить, скажем, shell на такой, который не держит за хвост свою
> текущую директорию, а открывает её только при подаче команды... (Правда, я и
Для shell-а это как раз не имеет смысла. Прибил его и дело с концом. У него внутреннего состояния практически нет, кроме той самой CWD. Переменные среды, определенные только для данного shell - большая редкость.
Беречь имеет смысл программы, у которых есть внутреннее состояние.
Скажем, текстовый редактор с открытым и модифицированным файлом.
Reply to: