OpenRC: failed because we are using /

Дал бы хоть линк на багзиллу

об этом знают все и без бго

Все? Я не знаю, не встречал за два года, на генте - несколько компов, в т.ч. два сервака.

но если так хочешь, вот свеженький https://bugs.gentoo.org/show_bug.cgi?id=430318

У меня стабильно появляется это сообщение после запуска `prelink -avfmR` и последующем выключении машины. Без ключа -f все нормально, или мы говорим о разных багах?

У меня при каждом выключении проявляется нечто подобное, только не про /, а про /tmp.

только на reiserFS проявляется?

у меня ext4. вроде тьфу-тьфу не было

Замечен этот же баг. корень на lvm. до этого не змечал. ветка ~amd64.

Это при выключении?

аптаймы - как правило недели, ext4. Ни разу не было.

это в функции do_unmount():

		while ! LC_ALL=C $cmd "$mnt" 2>/dev/null; do
			if type fuser >/dev/null 2>&1; then
				pids="$(fuser $f_opts "$mnt" 2>/dev/null)"
			fi
			case " $pids " in
				*" $$ "*)
					eend 1 "failed because we are using" \
					"$mnt"
					retry=0;;

вопрос, так, что видимо актуальный вопрос, почему openrc в списке использующих /?

Проявляется почти при каждом выключении. Закономерность выявить не удалось.

Не помню сколько юзаю генту, но такого бага ни разу не видел

Хотя, может быть я не обращал внимание

написано же - воспроизводится далеко не всегда

аха

в общем надо искать ответ на вопрос, почему текущий скрипт openrc, вызывающий do_unmout находится в списке fuser -m /.

Какими кактусами только не давятся, лишь бы не использовать systemd.

Баг проявлялся стабильно после использования e4rat-realloc.

У меня на сервере с софтварным рэйдом такое: массив разобрать невозможно потому что на нем /.

Где-то читал письмо от главного по линуксовому софт-рэйду, что ядро останавливает массивы само, без посторонней помощи, поэтому можно не сцать.

Это всё проделки Поттеринга...

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

и правда время от времени. закономерности не вижу.

п.с. аптайма больше одного дня у меня не бывает, на ночь комп выключаю

засунь себе эту systemd...сам знаешь куда

таки да - после prelink -amfR воспроизводится

в общем надо искать ответ на вопрос, почему текущий скрипт openrc, вызывающий do_unmout находится в списке fuser -m /.

мне вот тоже интересно
у меня после prelink -amfR воспроизводится
без оного нет
какое отношение прелинк имеет к openrc? o_O
а точнее к пиду вызывающего скрипта

я не шарю, как работает prelink, чтобы компетентно ответить на этот вопрос :( попробую узнать.

У меня чаще всего проявляется когда перед выключением в yakuake / открыт. А может быть мне просто кажется :D

кажется

забавно:
если зациклить цикл (^_^), то при мате sysrq комбинации корректно перемонтируют / в ro
почему alt+sysrq+u корректно монтирует, а {u}mount не может?
всякие lazy/force, естессно, приводят к жопе

почему alt+sysrq+u корректно монтирует, а {u}mount не может?

некомпетентный ответ: потому, что alt+sysrq+u это kernel, причём тот кусок который может делать всё безаппеляционно и его не волнует, что программы могут использовать отмонтируемый диск, а umount это userspace+kernel, который проверяет используется ли диск?

(про прелинк пока не узнавал)

таки разница не в этом - у {u}mount есть ключик --force
с ним тоже плевать кто там что использует

с ним тоже плевать кто там что использует

Нет, постоянно натыкаюсь на то, что umount --force не может отманутить что-нибудь.

Юзкейс - маунтишь флешку, делаешь cd в неё и пробушь отмаунтить.

таки кинули в меня хренью одной
в /etc/init.d/mount-ro
после синков запили строку
telinit u
всё будет работать как нать

Спасибо за ответ.

После синков, это, видимо, после

	# Flush all pending disk writes now
	sync; sync

Из мана telinit:

U or u tell init to re-execute itself (preserving the  state).  No  re-
              examining  of /etc/inittab file happens. Run level should be one
              of Ss0123456 otherwise request would be silently ignored.

Если ты разобрался с этим, то расскажи, пожалуйста, почему `telinit u` исправляет ситуацию.

всё правильно - без параметров
просто процитирую:

[01:31:09] <spike> сделай
telinit u
[01:31:25] <spike> init перезапустит сам себя
[01:31:46] <spike> и удалится старая версия бинарника созданная прелинком
[01:31:55] <spike> и / нормально отмонтируется

Спасибо, все понятно теперь.