Н-да, завершением процессов в целом и сетевых в частности, целая пачка проблем. С одной стороны стараются ускорить процесс завершения, а с другой это вылазит боком - процесс вовремя не завершается - не закрывает дескриптор файла и имеем "грязный диск" Кстати и режим гирбенации (на мой скромный взгляд ) забанили из-за этих глюков, а не из-за свопа как некоторые говорят.
modem-manager - есть вероятность, что он просто висит в процессах не портя диск...
Есть такой зверь "dhclient", он успешно игнорировал сигнал завершения. К нему вроде были фиксы, но... как бы не он один гадит. Самый простой способ лечения в таких случаях - установка статического IP.
Но прежде можно попробовать ручками отключать "управление сетью" и перезагрузиться, после чего посмотреть логи на предмет или диск был попорчен.
Способы борьбы с другими надо гуглить, в большинстве случаев решения уже описаны, а вот о том как вычислить кто вредничает ниже:
Но, прежде всего:
1) надо иметь представления о работе с терминалом.
2) создавать резервные копии файлов которые редактируются.
3) создать загрузочную флешку на случай ядерной войны.
4) проверить или в системе есть
lsof Набрать в терминале
lsof, энтер и станет понятно или есть...
Если есть проверить где он обитает поскольку в скрипте напишем
/usr/bin/lsof и если путь другой, то лог будет пустой. Проверить или правильный путь можно набрав в терминале
/usr/bin/lsofДалее в терминале:
Перед редактироанием делаем резервную копию файла следующим образом:
$ sudo cp -p -v /etc/init.d/umountroot /etc/init.d/umountroot.bakЗапускаем редактор:
$ sudo gedit /etc/init.d/umountrootВ открывшемся редакторе ищем строку 85 и после нее добавляем код который будет логировать список процессов которые держат открытыми на запись файлы к тому моменту, когда уже должны были все закрыть и завершить свое существование. Лог сохраняется в файл
myopenfiles:
/usr/bin/lsof | grep -e "[[:digit:]]\+w" > /myopenfilesпосле редактирования строки должны выглядеть примерно так:
85 # See #339023 and the comment in checkroot.sh
86 /usr/bin/lsof | grep -e "[[:digit:]]\+w" > /myopenfiles
87 mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/dev/null \
Сохраняем файл, перезагружаемся, идем в терминал, пишем - смотрим
$ sudo cat /myopenfilesinit 1 root 4w FIFO 0,8 0t0 7568 pipe
dhclient 1377 root 4w REG 8,4 1572 267975 /var/lib/dhcp/dhclient-...-eth0.lease
dnsmasq 1538 nobody 8w FIFO 0,8 0t0 10951 pipe
plymouthd 2211 root 5w FIFO 0,8 0t0 13325 pipe
lsof 2356 root 1w FIFO 0,8 0t0 12965 pipe
lsof 2356 root 5w FIFO 0,8 0t0 13400 pipe
grep 2357 root 1w REG 8,4 0 1651 /myopenfiles
lsof 2358 root 7w FIFO 0,8 0t0 13401 pipe
из залипших процессов lsof,grep - это наших рук дело, остальные - тормоза, которые вероятно попортят диск.
Кто есть кто и почему не завершается можно нагуглить.
После экспериментов обязательно идем в терминал и восстанавливаем из резервной копии:
$ sudo cp -p -v /etc/init.d/umountroot.bak /etc/init.d/umountrootили восстанавливаем состояние через редактор
$ sudo gedit /etc/init.d/umountrootв открытом в редакторе файле или убираем, или коментируем нашу строку "86", сохраняем файл - ибо не хватало к прочим, чтоб еще и своими руками созданный лог постоянно пакостил на диск.
Список залипших процессов даже на одной машине время от времени может менять состав.
Проблема с завершением касается в том числе и кубунты и лубунты...
Тема: Проверка системного раздела при загрузке (Прочитано 4728 раз)
