mount: / is busy
lsof или fuser тебе в помощь в поиске гадёныша.
Про lsof и fuser я само собой в курсе.
lsof | wc -l
14770
Очень многие из них расположены на корневом разделе. Что конкретно там искать-то?
lsof | wc -l
14770
Очень многие из них расположены на корневом разделе. Что конкретно там искать-то?
sync добавь перед вторым маунтом. А вообще ты какой-то ерундой занимаешься, без обид.
sync не помогает. 
Что конкретно там искать-то?Очевидно, открытые на запись файлы
Может новый рутовый шелл открывает на запись что-нибудь в /root ?
Не, у меня root -> /var/home/root (ну и home -> /var/home/ само собой).
Я сейчас пытаюсь подловить момент, когда эта фигня произойдёт.
Я сейчас пытаюсь подловить момент, когда эта фигня произойдёт.
fuser вроде умеет показывать какой доступ у процессов.
Не, у меня root -> /var/home/rootнафига?
В общем хрень случилась опять.
Вот вывод команды:
Если запустить, к примеру, vim /etc/whatever, то появляется строка:
root 27935 Fr.e. vim
Судя по ману, символизирующая с помощью заглавной F, что файл открыт как rw. В листинге выше таких файлов не наблюдается. Тем не менее, если выйти из вима и попытаться перемонтировать, увижу до боли знакомое mount: / is busy
Вот вывод команды:
# fuser -v -m /
USER PID ACCESS COMMAND
/: root kernel mount /
root 1 .rce. init
root 2 .rc.. kthreadd
root 3 .rc.. ksoftirqd/0
root 6 .rc.. migration/0
root 7 .rc.. migration/1
root 9 .rc.. ksoftirqd/1
root 11 .rc.. khelper
root 12 .rc.. kdevtmpfs
root 13 .rc.. netns
root 14 .rc.. kworker/u:1
root 94 .rc.. sync_supers
root 96 .rc.. bdi-default
root 98 .rc.. kblockd
root 104 .rc.. ata_sff
root 250 .rc.. kswapd0
root 315 .rc.. fsnotify_mark
root 329 .rc.. crypto
root 372 .rc.. scsi_eh_0
root 375 .rc.. scsi_eh_1
root 378 .rc.. scsi_eh_2
root 381 .rc.. scsi_eh_3
root 397 .rc.. scsi_eh_4
root 400 .rc.. scsi_eh_5
root 404 .rc.. kworker/u:7
root 413 .rc.. kpsmoused
root 466 .rc.. ext4-dio-unwrit
root 548 .rce. udevd
root 588 .rc.. khubd
root 590 .rc.. cfg80211
root 591 .rc.. hd-audio0
root 598 .rc.. hd-audio1
root 805 .rc.. iprt
root 881 .rc.. ext4-dio-unwrit
root 882 .rc.. jbd2/sda8-8
root 883 .rc.. ext4-dio-unwrit
root 884 .rc.. jbd2/sda11-8
root 885 .rc.. ext4-dio-unwrit
root 886 .rc.. jbd2/sdc1-8
root 887 .rc.. ext4-dio-unwrit
root 888 .rc.. jbd2/sdd1-8
root 889 .rc.. ext4-dio-unwrit
root 1222 .rce. syslog-ng
root 1223 .r.e. syslog-ng
root 1421 .r.e. fcron
root 1426 .rce. hostapd
root 1432 .rc.. flush-8:0
root 1444 .rce. dhclient
mpd 1623 .rce. mpd
root 1627 .rce. cupsd
root 1629 .rce. pppd
root 1636 .rce. sshd
nobody 1666 .rce. noip2
tot-to 1682 .rce. transmission-da
tot-to 1798 .r.e. bash
root 1799 .rce. agetty
root 1800 .rce. agetty
root 1801 .rce. agetty
root 1802 .rce. agetty
root 1803 .rce. agetty
tot-to 17666 fr.e. startx
tot-to 17682 .r.e. xinit
root 17683 fr.e. X
tot-to 17698 .r.e. ion3
tot-to 17704 .r.e. docker
tot-to 17705 .r.e. ion-statusd
root 17715 .r.e. sudo
browser 17716 .r.e. uzbl-core
browser 17719 .rce. python2
browser 17773 .r.e. uzbl-core
tot-to 17797 .r.e. psi-plus
tot-to 17821 .r.e. claws-mail
tot-to 17848 .r.e. linphone
tot-to 17851 .r.e. urxvt
tot-to 17852 .r.e. bash
tot-to 17956 fr.e. qstardict
tot-to 18010 fr.e. emelfm2
tot-to 18818 .r.e. urxvt
tot-to 18819 .r.e. bash
tot-to 18844 .r.e. less
tot-to 19628 .r.e. urxvt
tot-to 19629 .r.e. bash
root 22698 .rc.. kworker/0:0
tot-to 22799 .r.e. urxvt
tot-to 22800 .r.e. bash
tot-to 22824 .r.e. leafpad
tot-to 23381 .r.e. canto
root 24427 .rc.. scsi_eh_6
root 24431 .rc.. usb-storage
tot-to 25358 .r.e. urxvt
tot-to 25359 .r.e. bash
tot-to 25530 .r.e. ssh
root 25744 .rc.. kworker/0:2
root 26974 .rc.. kworker/1:1
root 27288 .rc.. kworker/1:0
root 27386 .r.e. bash
root 27392 .rc.. flush-8:16
tot-to 27679 .r.e. urxvt
tot-to 27680 fr.e. ion-runinxterm
tot-to 27681 fr.e. man
tot-to 27683 fr.e. sh
tot-to 27685 fr.e. less
root 27703 .rc.. kworker/1:2
tot-to 27738 .r.e. urxvt
tot-to 27739 .r.e. bash
root 27743 .r.e. bash
Если запустить, к примеру, vim /etc/whatever, то появляется строка:
root 27935 Fr.e. vim
Судя по ману, символизирующая с помощью заглавной F, что файл открыт как rw. В листинге выше таких файлов не наблюдается. Тем не менее, если выйти из вима и попытаться перемонтировать, увижу до боли знакомое mount: / is busy
Очевидно, открытые на запись файлыоткрытые анлинкнутые файлы тоже блокируют ро-румаунт
вместо ремаунта rw-ro можно сделать отдельный rw chroot для апдейтов, а корень оставить ro.
вместо ремаунта rw-ro можно сделать отдельный rw chroot для апдейтов, а корень оставить ro.У меня как раз есть раздел на hdd, куда rsync периодически бекапит раздел с ssd. Я так понимаю, что на него можно продублировать все маунты, которые есть к корню, типа /var /tmp и так далее, затем chrootнуться туда и обновиться. Так?
Ну хорошо, а потом-то как эти изменения залить на корень без перемаунчивания? Не один ли хрен надо перемаунчивать?
нет, одна фс может быть смонтирована в джва места — один рв второй ро. ака read-only bind mount.
какая ФС и что с mtab?
нет, одна фс может быть смонтирована в джва места — один рв второй ро. ака read-only bind mount.Спасибо, изучу вопрос.
какая ФС и что с mtab?/etc/mtab у меня симлинк на /proc/mounts
Вот его содержимое, касательно корня:
rootfs / rootfs rw 0 0
/dev/root / ext4 ro,relatime,barrier=1 0 0
Но это мне сейчас пришлось перезагрузиться. Когда проблема снова появится, я снова туда загляну.
/dev/root / ext4 ro,relatime,barrier=1 0 0Может стоит noatime попробовать? Обновление atime-ов не может помешать перемонтированию?
неа, remount в ro возвращет EBUSY если есть то что нельзя записать прямо сейчас — открытые на запись или анлинкнутые файлы. atime update просто игнорируется если у нас ro.
Имхо, ты делаешь всё неправильно. У меня какая ситуация была: купил себе OCZ Vertex 2 100GB, поставил систему на него, все доки, ставил туда все программы. Настроил стандартный виндовый бэкап на старый 2TB диск раз в день.
Через 8 месяцев (вроде) SSD накрылся из-за бага со спящим режимом (как мне кажется). Отвез в гарантийку, там говорят: "мы SSD не ремонтируем, вот вам справка, поднимитесь в магазин, вам деньги отдадут". Поднялся в магазин, отдал справку, через пару дней курьером вернули деньги.
Открыл сайт йошопа, стал смотреть новый SSD. Вижу, Vertex'ы подешевели, теперь на деньги, что мне вернули я мог купить 120ГБ версию и ещё осталось бы немного. Я подумал, добавил чутка, купил 140ГБ.
Восстановился из бекапа за полчаса. Жду, когда в очередной раз полетит. Харды ещё подешевели, а гарантия - три года.
Через 8 месяцев (вроде) SSD накрылся из-за бага со спящим режимом (как мне кажется). Отвез в гарантийку, там говорят: "мы SSD не ремонтируем, вот вам справка, поднимитесь в магазин, вам деньги отдадут". Поднялся в магазин, отдал справку, через пару дней курьером вернули деньги.
Открыл сайт йошопа, стал смотреть новый SSD. Вижу, Vertex'ы подешевели, теперь на деньги, что мне вернули я мог купить 120ГБ версию и ещё осталось бы немного. Я подумал, добавил чутка, купил 140ГБ.
Восстановился из бекапа за полчаса. Жду, когда в очередной раз полетит. Харды ещё подешевели, а гарантия - три года.
Может стоит noatime попробовать? Обновление atime-ов не может помешать перемонтированию?Ну вообще в fstab я написал noatime. И когда я перемонтирую в rw, то меняется не только ro на rw.
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,noatime,barrier=1,discard 0 0
Ну то есть у тебя он сдох не из-за количества перезаписей?
Просто мне почему-то кажется, что сдыхание из-за количества перезаписей не будет гарантийным случаем. Иначе я могу и спецом перед окончанием гарантии погонять в бесконечном цикле на нём dd и вернуть деньги.
Просто мне почему-то кажется, что сдыхание из-за количества перезаписей не будет гарантийным случаем. Иначе я могу и спецом перед окончанием гарантии погонять в бесконечном цикле на нём dd и вернуть деньги.
неа, remount в ro блокируется если есть то что нельзя записать прямо сейчас — открытые на запись или анлинкнутые файлы.хм, и давно?
Просто мне почему-то кажется, что сдыхание из-за количества перезаписей не будет гарантийным случаем.Прежде, чем заниматься возможно совершенно не нужным сексом с монтированием и перемонтированием, лучше бы узнал точно. Тем более, я, вроде, где-то видел, что в режиме непрерывной перезаписи ожидается несколько лет работы.
да, где-то здесь, но что-то за полминуты поиска не нашел.
http://www.storagesearch.com/ssdmyths-endurance.html
http://www.storagesearch.com/ssdmyths-endurance.html
Правильно тебе написали про lsof. Надо искать удаленные, но запущенные бинарники. У меня такая же штука, как у тебя: и gentoo и ssd ro для rootfs. После одновления смотри, что удалено с корня, но открыто:
Так, например, если ты обновил постоянно запущенный sshd, то тебе его надо перезапустить, чтобы был запущен (открыт с диска) уже новый файл, а не старый удалённый. Я обновляюсь в ручную, поэтому отыскивыю все такие процессы тоже самостоятельно.
lsof / | grep DEL
Так, например, если ты обновил постоянно запущенный sshd, то тебе его надо перезапустить, чтобы был запущен (открыт с диска) уже новый файл, а не старый удалённый. Я обновляюсь в ручную, поэтому отыскивыю все такие процессы тоже самостоятельно.
Я тут уже разобрался с тем, чтобы обновляться в chroot, примонтировав корень в другом месте. Если наделать алиасов и/или скриптов, то будет вполне себе удобно.
Попробую и твой вариант. Это, очевидно, более прямое решение
Спасибо!
Попробую и твой вариант. Это, очевидно, более прямое решение
Спасибо!
хм, и давно?анлинкнутые недавно добавили, в принципе их можно внести в орфан-лист и удалить на следующем монтировании, но никому это писать не хочется.
я неточно выразился "блокируется" в смысле невозможен и возвращает EBUSY
То есть я так понимаю, что при обычном отмонтировании unlincked файлы просто удаляются?
А что тогда происходит при предложенном тобою подходе с bind mount в rw? Не получается ли так, что они вообще не удаляются?
Причём в случае с ssd, ещё важно, чтобы прошла команда TRIM, которая сообщает контроллеру об освобождении ячейки и обеспечивается опцией монтирования discard.
А что тогда происходит при предложенном тобою подходе с bind mount в rw? Не получается ли так, что они вообще не удаляются?
Причём в случае с ssd, ещё важно, чтобы прошла команда TRIM, которая сообщает контроллеру об освобождении ячейки и обеспечивается опцией монтирования discard.
То есть я так понимаю, что при обычном отмонтировании unlincked файлы просто удаляются? А что тогда происходит при предложенном тобою подходе с bind mount в rw? Не получается ли так, что они вообще не удаляются?удаляются они на закрытии, а пока открыты отмонтировать этот маунтпоинт не получится.
если их отрыли через ro bind-mount а удалили через rw, то rw прекрасно отмонтируется,
а ro нет пока файлы не закроют. при этом суперблок фс скорее всего останется в rw.
если сделать детач, то маунтпоинт в свою очередь уничтожится когда все файлы закроют.
если сделать детач, то маунтпоинт в свою очередь уничтожится когда все файлы закроют.Что-то эта фраза у меня нераспарсилась...
detach - это umount или что-то иное? Я погуглил по фразе "detach filesystem linux", первой выдаётся веб-серия man umount.
Маунтпоинт - это как бы просто директория, куда монтируется fs. Почему она должна уничтожаться?
detach это "umount -l", при этом маунтпоинт отделяется от дерева и болтается пока на него есть ссылки.
Я просто смотрю на это со стороны ядра, там vfsmount это отдельная структура которая живёт независимо.
Например vfsmount не обязан жить всё время в одном месте, "mount --move" прекрасно двигает его куда угодно.
Я просто смотрю на это со стороны ядра, там vfsmount это отдельная структура которая живёт независимо.
Например vfsmount не обязан жить всё время в одном месте, "mount --move" прекрасно двигает его куда угодно.
Теперь всё ясно. Спасибо!
Главное, что файлы в итоге будут верно удалены и ядро не забует сказать TRIM контроллеру.
Главное, что файлы в итоге будут верно удалены и ядро не забует сказать TRIM контроллеру.
Апну тему, поскольку сейчас снова появилась такая ситуация, причём
lsof / | grep DEL
ничего не выдаёт (после перезапуска тех программ, что выдавал), а в списке, выдаваемом
fuser -v -m /
нет заглавной F, но при этом перемонтирование не происходит, выдавая всё тот же
mount: / is busy
UPD: о, юбилейный пост. Тогда посвящаю его борьбе с НЁХ в мире UNIX.
lsof / | grep DEL
ничего не выдаёт (после перезапуска тех программ, что выдавал), а в списке, выдаваемом
fuser -v -m /
нет заглавной F, но при этом перемонтирование не происходит, выдавая всё тот же
mount: / is busy
UPD: о, юбилейный пост. Тогда посвящаю его борьбе с НЁХ в мире UNIX.
В нормальных дистрибутивах проблема давно известна и есть инструменты для её решения. Возьми этот скрипт и доделай под генту. Он выдает бинарники, которые не показывает ни lsof, ни fuser.
В нормальных дистрибутивах проблема давно известна и есть инструменты для её решения. Возьми этот скрипт и доделай под генту. Он выдает бинарники, которые не показывает ни lsof, ни fuser.Да, действительно в нормальном дистрибутиве такой скрипт есть.
$ eix checkrestart
* app-admin/checkrestart
Available versions: (~)0.47-r2
Homepage: http://arcdraco.net/checkrestart
Description: the sysadmin's rolling upgrade tool
Спасибо, попробую.
почему же о нем не написано в документации к этому чудесному дистрибутиву?
Он выдает бинарники, которые не показывает ни lsof, ни fuser.В чём прикол, если это надстройка над lsof?
поглядел - видимо в правильных опциях
и каковы же они?
lsof +XL -F nf
кстати, в теории - скрипт может использовать не только lsof (на практике эта возможность выключена и написано TODO, что надо бы починить эту функциональность)
а что особенного в них? только удобство разбора скриптом, вроде какой-то тайной информации нет
мне лень читать ман, но они явно выводят те файлы, которых нет в выводе того, что раньше тут предлагали.
мне лень читать манДа, в этом вся соль.
таки я предлагаю самым умным (ака тем, кому надо) самим его прочитать.
Оставить комментарий
dangerr
Сделал себе систему с read only корнем на ssd. Всё отлично работает, но чтобы обновить систему или отредактировать конфиг, конечно, надо перемонтировать в rw, а затем опять в ro.Например, для обновления используется команда:
mount -w -o remount /; emerge -uDN --with-bdeps=y system world; mount -r -o remount /
Причём после такой команды в зависимости от погоды на Марсе перемонтирование обратно в read only может как сработать, так и нет, выдав малоинформативное "mount: / is busy". После этого вернуться обратно в ro получается только методом перезагрузки.
В чём может быть дело? Ладно бы вообще не перемонтировалось, можно было бы объяснить это тем, что всегда существуют открытые файлы. А тут какая-то мистика.