В сообщении от 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
