Как я могу перезагрузить Linux вместо перемонтирования файловой системы только для чтения?

Я бы также исследовал источник этих ошибок ввода-вывода.В последний раз, когда файловая система ext2 была у меня доступна только для чтения, это было в 1994 году, и причина могла быть связана со сломанным вентилятором процессора.

У вас здесь [проблема XY] (https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). Правильное решение состоит не в том, чтобы перезагрузить систему при ошибке ввода-вывода (принятый ответ объясняет, как это сделать, _но_ это довольно рискованно по нескольким причинам), а в том, чтобы _исправить основную причину ошибок ввода-вывода_ , потому что тогда файловая система не будет случайно смонтирована только для чтения. Если это только прерывисто, а устройство хранения в порядке, у вас, вероятно, есть подозрение на ОЗУ или ненадежный блок питания, оба из которых могут вызвать гораздо более серьезные проблемы, чем простая ошибка файловой системы.

@AustinHemmelgarn: у меня нет проблемы с XY. Вы просто делаете много предположений, которые не соответствуют действительности в случаях, о которых я спрашиваю.

@SimonRichter: я действительно пытался выяснить причину, но спасибо за напоминание, другим, вероятно, следует сделать это перед перезагрузкой.

Я только что понял, что как-то разместил это на ServerFault, а не на Unix.SE, как собирался! Рад, что это все еще в теме, я думаю, но не стесняйтесь мигрировать, если это необходимо.

Перезагрузка, а не выяснение причины повторного монтирования R/O, с высокой вероятностью усугубит проблему, особенно если не удается смонтировать систему при перезагрузке, и теперь вы застряли с полностью не отвечающей системой.

@ user541686 У вас случайные ошибки ввода-вывода. Это _вызовет_ в конечном итоге другие проблемы (и поверьте мне, исправить их будет гораздо сложнее, чем просто перезагрузить систему), поэтому я утверждаю, что это проблема XY. Тот факт, что вы не признаете X проблемой, не делает ее менее проблемой XY.

@AustinHemmelgarn: я хорошо знаю, что происходит в моей ситуации, и почему я прибег к этому решению. К сожалению, это не так. Тот факт, что вы не осознаете, что все еще делаете необоснованные предположения о моей ситуации, не делает вас более правильным, но, по общему признанию, я не могу помешать вам читать лекции.

@Shadur: я все это прекрасно понимаю, хотите верьте, хотите нет. Никто не говорит, что это решение следует использовать в любой ситуации. Я просто говорю вам, что у меня есть **чертовски** ситуация, когда это решение имеет смысл. Если вы не можете себе представить, почему, это нормально. Просто поверь мне, что я не дурак и что я спрашиваю об этом только потому, что у меня есть информация, которой нет у тебя.

@ user541686, если есть соответствующая информация, предоставьте ее. Не говорите просто «доверься мне».

@Mark: Нет, я не буду предоставлять ненужную информацию. Буквально никого не касается, в какой ситуации я имею дело, что вызвало этот вопрос. Если вы предпочитаете верить, что это из-за моей глупости, не стесняйтесь продолжать верить в это; не чувствуйте себя обязанным «доверять мне». Я не могу заставить тебя.

@user541686 user541686 Вы устраняете ошибки ввода-вывода в корневой файловой системе с помощью перезагрузки, *** НАДЕЯСЬ ***, что ваша система вернется в рабочее состояние. Вы производите впечатление человека, который думает, что знает все, но на самом деле достаточно умен, чтобы быть опасным. Вы можете думать, что знаете, почему вы получаете ошибки ввода-вывода, но что происходит, **когда** вы получаете ошибку, которая не соответствует вашим представлениям? Вы получаете мертвую систему, к которой вы не можете получить доступ. "Я знаю, что происходит!" не накладывает никаких ограничений на то, что **может** продолжаться — вселенной нет дела до того, что вы думаете, что знаете.

@Mark (и другие) _ "... если есть соответствующая информация, предоставьте ее. Не говорите просто "доверься мне"". _ - Я не думаю, что здесь стоит лаять дерево XY. Прежде всего, вопрос в его нынешнем виде (паника / перезагрузка вместо перемонтирования ro) является вполне обоснованным и на него можно ответить. Во-вторых, ОП, кажется, хорошо знает, что ошибки ввода-вывода, кхм, не идеальны, и теперь явно объявил эту область не по теме. К сожалению, иногда вы ничего не можете сделать, чтобы исправить основную причину _прямо сейчас_, и требуется обходной путь. Имея это в виду, я не думаю, что мы находимся в том положении, чтобы требовать от ОП предоставления большего контекста.

Альтернативой сторожевому таймеру может быть добавление чего-то вроде `kernel.panic = 5` в `/etc/sysctl.d/panic-reboot.conf`.

Спасибо! Я попробую. Надеюсь, это не [не удастся перезагрузить](https://forums.debian.net//viewtopic.php?f=5&t=102033)!

@NikitaKipriyanov хорошее предложение, я отредактирую свой ответ. Спасибо.

предупреждение: возможная петля перезагрузки

@joshudson: Да, я планирую следить за этим, это определенно важное предупреждение для всех, кто пытается это сделать.

@joshudson Если он вообще перезагрузится. Полагаться на систему, которая знает, что ее корневая файловая система может быть повреждена и/или ее корневой диск неисправен для перезагрузки, основано на принятии желаемого за действительное и единорогах.

@AndrewHenle: я поднял много систем с поврежденной корневой файловой системой. Обычно я могу взять на себя процесс загрузки и запустить fsck, потому что повреждение редко затрагивает `/sbin` или файлы, которые не менялись какое-то время.

@joshudson Вы надеетесь ... ;-) Мои мысли здесь основаны на идее о том, что попытка бороться с тем, когда ваше устройство с корневой файловой системой выдает ошибки ввода-вывода, в первую очередь является ошибочным усилием, а перезагрузка только усугубляет серьезные проблемы. вероятно - «Мое корневое устройство выходит из строя, поэтому давайте сделаем что-нибудь, что *** действительно *** зависит от того, будет ли корневое устройство полностью функциональным и имеет надлежащий доступ к большей части файловой системы!»

+1 спасибо, это будет отличным запасным вариантом, если другое решение не сработает!

Я думаю, что не гарантируется, что `test -w` проверяет, доступна ли файловая система для чтения и записи. Хотя GNU `test` и `test`, встроенные в `bash`, кажется, делают это. --- Здесь вы можете увидеть, что должен делать POSIX-совместимый `test`: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag_20_128_05 Насколько я понимаю, `test` требуется только для проверки права доступа к файлу.

В этом случае `tee -a /root/.bash_history

@joshudson Еще проще: `touch /writecheck || перезагрузить`

@shodanshok Это здорово, если вы не возражаете против файла с именем `/ writecheck`, лежащего в корне вашей файловой системы, поскольку он будет создан, когда файловая система _не_ будет доступна только для чтения. Другие предложенные методы пытались избежать создания ложных пустых файлов. (Хотя, если Пабук прав — в чем я лично 50/50 — на самом деле создание файла может быть неизбежным, чтобы полностью определить состояние файловой системы только для чтения.)

Еще один вопрос о проблеме тестирования доступа на запись: [Как неинвазивно проверить доступ на запись в файл?] (https://unix.stackexchange.com/q/159557/19702)

@shodanshok, которые могут привести к неожиданным перезагрузкам - или циклам перезагрузки - из-за ошибок, не связанных с ошибками файловой системы, например, временные сбои установки libc, условия OOM, все, что может привести к сбою touch ....

@rackandboneman уверен, но *любой* скрипт с `|| reboot` подвержен этим проблемам. Более того, если `touch` не работает в вашей системе из-за проблем с libc, у вас, вероятно, есть более серьезная проблема, чем цикл перезагрузки. В любом случае, как указано в моем ответе, «сторожевой пес» - это способ удовлетворить более продвинутые потребности.

Этот вопрос на других языках: