[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CD/DVD ROM eject: решение (или грабли?) вместо ivman



В сообщении от 1 марта 2006 10:10 Victor Wagner написал(a):

> > Однако если хоть один процесс его держит, umount, если я правильно
> > понимаю, просто не сработает :( А если не держит - так через таймаут
> > (скажем, 3 секунды) autofs тоже сделает размонтирование.
>
> Насколько я понимаю, если файловая  система уже недоступна, то ядро в
> этом случае ведет себя немножко по-другому. Опять же ключик -f у umount
> есть.

Ключик -f в данном, случае, к сожалению, не срабатывает - я проверял. 

Но я тут подумал, что падение CD/DVD-ROM в device not ready _обязано_ 
корректно отрабатываться в любом случае, а если не отрабатывается - это баг 
(не знаю, в iso9660 fs или нет...)

Дело в том, что такое падение умеет происходить при чтении очень плохих 
дисков. А это - штатная ситуация.

> Затем что если ты вытаскиваешь диск, то shell у которого CWD на этом диске
> тебе уже не нужен. shell-ы это вообще расходный материал - для каждого
> скрипта новая копия запускается.

А если в этом шелле сидел совсем-другой-юзер?

> А если у тебя есть файлменеджер, который держит директорию на съемном
> носителе, и не отрабатывает корректно сигнал, то такой файлменеджер
> убивать надо не сигналом а aptitude remove.

Какой сигнал? Разве есть сигнал, означающий "из-под тебя убрали файловую 
систему"? 

> Собственно есть две ситуации:
> 1. Мелкая (в стиле unix-way) программа, которая была запущена специально
> для работы с данными на этом диске. А потом просто пользователь забыл её
> закрыть. Тогда прибивание программы по событию вытаскивания диска -
> нормальное явление. Юзер не закрыл - система для него закроет.

Сценарий при этом варианте:

login: xxx
password: xxx
[insert disk]
$ cd /mnt/cdrom
[disk automounted]
$ cp * ~/incoming
[copying...]
$
[eject disk, logon shell crashed]
login:

[user: WTF?!?!]

> В данном случае падение программы при вытаскивании  диска делает просто
> более заметным факт, что эта программа с диском неаккуратно обращается.
> И, следовательно, должна быть либо исправлена, либо заменена на более
> правильную.

Если бы не привычка шеллов (а значит - неизбежно - и файломенеджеров, 
держжащих шеллы, вроде mc, даже если написать более прямо) держать текущую 
директорию, я бы согласился.

> Лично я не понимаю какая нафиг разница между fail-ящимся системным
> вызовом и прилетающим сигналом. И то, и другое может быть программой
> обработано. И то, и другое по умолчанию приводит к падению программы.
>
> В данном случае реализация особой ситуации посредством посылки сигнала
> обходится намного проще чем реализация её посредством возврата ошибки из
> системного вызова.

Только если бы это был не SIGKILL...

> Для shell-а это как раз не имеет смысла. Прибил его и дело с концом. У него
> внутреннего состояния практически нет, кроме той самой CWD. Переменные
> среды, определенные только для данного shell - большая редкость.
> Беречь имеет смысл программы, у которых есть внутреннее состояние.
> Скажем, текстовый редактор с открытым и модифицированным файлом.

Погоди, а вот ещё один сценарий

/mnt/cdrom$ emacs

[long work..]
[eject CD]
[emacs crashes as parent is killed!]

У shell'а ещё и дети есть...

-- 
Yours, Mikhail Ramendik



Reply to: