Я обновил свой сервер до Debian wheezy и поиграл с ним. Через некоторое время я захотел перезагрузить компьютер и обнаружил ошибку
shutdown: /run/initctl: No such file or directory
Я искал в Интернете и узнал, что initctl происходит от выскочки. Даже если он не установлен в соответствии с aptitude, а service команда sysvinit по-прежнему работает. Я ценю любую помощь.
Я искал в Интернете и узнал, что initctl происходит от выскочки.
Эта ошибка - то, что вы получаете от исследования поисковой системой, а не справочной страницей.
На самом деле это имя /run/initctl . Upstart имеет /sbin/initctl . Это совершенно разные вещи. Первый - это FIFO, который используется для отправки команд управления процессу № 1. Последний является программным файлом.
Первоначально (клон Linux) System V init создавал в процессе # 1 во время загрузки FIFO с именем /dev/initctl . Такие программы, как telinit работали, открывая этот FIFO и записывая в него сообщения, которые процесс № 1 будет читать и действовать.
Такие системы, как Upstart, finit Йоахима Нильссона и systemd, предоставляют совместимые прокладки, которые создают FIFO в /dev/initctl , прослушивают сообщения и переводят команды из концепций System V в эквиваленты finit/Upstart/systemd. Таким образом, инструменты, ожидающие init программы инициализации System V, могут по-прежнему открывать этот FIFO и записывать ему команды. (Однако не все системы инициализации предоставляют такие прокладки. И если вы спросите людей init Debian System V они скажут вам , что это плохо документированы внутренний API , что программы , которые не являются частью системы V пучка не должны действительно использовать в первую очередь.)
Тогда, несколько лет назад, в Debian System V init люди решили , что FIFO собирается перейти от /dev/initctl к /run/initctl Поэтому они изменили свой init чтобы создать его там, и изменили все инструменты, которые идут с его init - такие как shutdown , halt , telinit и т.д. - чтобы найти его там.
Они только сообщили разработчикам одной из других систем, хотя. Таким образом, когда системы init отличные от System V, управляют системой, они по-прежнему в основном предоставляют свои совместимые FIFO- файлы в /dev/initctl . Если init инструмент инициализации System V с такой системой init , отличной от System V, инструмент попытается открыть FIFO в новом месте, в то время как система предоставляет его в старом месте.
К настоящему времени обходной путь должен быть очевиден: быстрое символическое соединение делает свое дело.
ln -s /dev/initctl /run/initctlИ это длится до следующей перезагрузки (когда, по-видимому, кто-то перезапустил систему в более разумную конфигурацию, которая не смешивает системы инициализации, и которая попытается создать сам FIFO). Роджер Ли, один из сопровождающих пакета
init Debian System V, отметил это в 2012 году.
Обратите внимание, что на самом деле совсем не обязательно использовать инструменты init System V. Отсутствие совместимости с FIMO во многих системах инициализации не так уж важно. systemd, Upstart, nosh и другие системы, как правило, предоставляют свои собственные версии инструментов, таких как halt , reboot , telinit и так далее, в любом случае. Эти инструменты используют собственные протоколы соответствующих систем и не используют initctl FIFO вообще. Оболочки systemd говорят непосредственно о соответствующих протоколах D-Bus для обработки # 1. Прокладки Upstart генерируют соответствующие события upstart напрямую. Прокладки Ноша посылают соответствующие сигналы непосредственно процессу № 1.
Все это возится в другом ответе, и комментарии сводятся к двум пунктам:
/bin/bash как процесс № 1, а не с какой-то реальной системой инициализации, то, конечно , нигде не будет FIFO initctl . Как уже упоминалось, это система инициализации, которая создает его. Сызнова. На каждом бутстрапе.mkfifo волшебным образом не приводит к появлению сервера, который должен прослушивать сообщения в конце чтения FIFO . Вот почему последующие попытки утилит для отправки сообщений по FIFO не работают.То, как вам удалось привести Debian 7 в состояние, в котором он использует инструменты init System V, но в то время запускает другую систему инициализации, - это совсем другое дело. Это вполне возможно, особенно когда вы переключаетесь между системами инициализации. В действительности это не все было решено для Debian 7, и есть некоторые странные состояния, в которые может попасть система. В Debian 8 не все гладко и закончено (как есть), даже. К счастью, это был не твой вопрос. ☺
initctl(8). Страницы руководства по Ubuntu./dev/initctl в /run. 638019. Система отслеживания ошибок Debian.debian/patches/93_run_initctl.patch. alioth.debian.org.halt , poweroff , reboot. Системные справочные страницы. freedesktop.org.reboot(8), halt(8), poweroff(8). Страницы руководства по Ubuntu.У меня была точно такая же проблема с raspbian wheezy, которую я использую на эмуляторе RPi в qemu. Я, кажется, решил проблему для моей конкретной установки. Работает ли это для вас - другое дело. Я надеюсь, что это так. Я буду честен и скажу, что я не уверен, в чем была проблема, или как она сама себя исправила, но я задокументировал все, что сделал, и не пропустил ни одного шага.
Я настроил эмулированный Raspberry Pi, используя qemu, используя эти два руководства 1:
При первой загрузке qemu с помощью команды (обратите внимание на использование init=/bin/bash)
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img
как только система загрузилась, я обнаружил, как и OP, что команда halt не будет запущена, вместо этого появится ошибка:
init: /run/initctl: No such file or directory
Затем я запустился (любезно, я получил флаг ошибки "init: /dev /initctl: нет такого файла")
mkfifo /run/initctl
который остановил No such file or directory ошибки каталога , но все еще не выключил систему, вместо этого выдав ошибку
init: timeout opening/writing control channel /run/initctl.
Я сравнил только что созданный /run/initctl с рабочим RPi, используя ls -l /run/initctl и они выглядели одинаково:
prw------- 1 root root 0 Jan 1 1970 /run/initctl
Я нажимал на шаги руководства независимо от того, после reboot -f . Теперь этот следующий шаг - то, где исправление произошло, я верю. Я запустил qemu RPi с "нормальной" загрузкой, оставив init=/bin/bash
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
Wheezy загрузился в raspi-config . Я просто изменил пароль пользователя pi и имя хоста, и нажал, и система перезагрузилась. Затем я снова запустил RPE QEMU с
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
Он загрузился в экран входа в систему tty. Я залогинился, запустил startx . После запуска X я запустил sudo shutdown -h now . Он выключился и остановился, как и ожидалось, без каких-либо ошибок init:
Загрузка (виртуального) устройства без init=/bin/bash похоже, исправила проблему. Был ли это эквивалент жесткой загрузки, которая должна решить проблему 2, или это была комбинация mkfifo и reboot , я не уверен. Не мой лучший ответ, который я знаю, но, надеюсь, он поможет.
1 В случае смерти ссылки слишком много информации, чтобы попытаться ее обобщить. Тем не менее, установка в значительной степени не имеет отношения к проблеме OP.
2 В соответствии с невозможностью перезагрузить debian и systemd-sysv, sysvinit: проблемы с перезагрузкой при переключении между systemd-sysv и sysvinit