shutdown: /run/initctl: нет такого файла или каталога

Я искал в Интернете и узнал, что initctl происходит от выскочки.

Эта ошибка - то, что вы получаете от исследования поисковой системой, а не справочной страницей.

Имя на самом деле /run/initctl, Выскочка имеет /sbin/initctl, Это совершенно разные вещи. Первый - это FIFO, который используется для отправки команд управления процессу № 1. Последний является программным файлом.

Первоначально, (клон Linux) System V init создаст в процессе #1 во время загрузки FIFO с именем /dev/initctl, Такие программы, как telinit управляет открытием этого FIFO и написанием ему сообщений, что процесс #1 будет читать и действовать.

Такие системы, как Upstart, Joachim Nilsson's finit и systemd обеспечивают совместимость прокладок, которые создают FIFO в /dev/initctl прослушивайте сообщения и переводите команды из концепций System V в эквиваленты finit/ upstart/systemd. Так что инструменты, которые ожидают System V init Программа, которая должна быть запущена, все еще может открыть этот FIFO и записать в него команды. (Однако не все системы инициализации предоставляют такие прокладки. И если вы спросите Debian System V init люди, которые скажут вам, что это плохо документированный внутренний API, который программы, не входящие в комплект System V, вообще не должны использовать.)

Затем, несколько лет назад, Debian System V init люди решили, что ФИФО собирается переехать из /dev/initctl в /run/initctl, Таким образом, они изменили свои init чтобы создать его там, и изменил все инструменты, которые идут с их init - такие как shutdown, halt, telinit и так далее - искать его там.

Они только сказали разработчикам одной из других систем, хотя. Поэтому, когда не System V init системы управляют системой, они по-прежнему в основном предоставляют свои FIMO совместимости /dev/initctl, Если смешать систему V init инструмент с таким не-System V init система, затем инструмент попытается открыть FIFO в новом месте, в то время как система предоставляет его в старом месте.

К настоящему времени обходной путь должен быть очевиден: быстрое символическое соединение делает свое дело.

 ln -s / dev / initctl /run/initctl 

И это продолжается до следующей перезагрузки (когда, по-видимому, кто-то перезапустил систему в более разумную конфигурацию, которая не смешивает системы инициализации, и которая попытается создать сам FIFO). Роджер Ли, один из разработчиков Debian System V init пакет, указал на это в 2012 году.

Обратите внимание, что на самом деле нет необходимости использовать System V init инструменты, вообще. Отсутствие совместимости с FIMO во многих системах инициализации не так уж важно. systemd, Upstart, nosh и другие системы, как правило, предоставляют свои собственные версии инструментов, таких как halt, reboot, telinit и так далее, в любом случае. Эти инструменты говорят о собственных протоколах соответствующих систем и не используют initctl ФИФО на всех. Оболочки systemd говорят непосредственно о соответствующих протоколах D-Bus для обработки #1. Прокладки Upstart генерируют соответствующие события upstart напрямую. Прокладки Ноша посылают соответствующие сигналы непосредственно процессу № 1.

Все это возится в другом ответе, и комментарии сводятся к двум пунктам:

• Если вы загружаетесь с /bin/bash как процесс № 1, а не какая-то действительная система инициализации, то, конечно, не будет initctl FIFO где угодно. Как уже упоминалось, это система инициализации, которая создает его. Сызнова. На каждом бутстрапе.
• И это система инициализации, которая отвечает на это. Создание FIFO вручную с mkfifo волшебным образом не создает сервер, который должен прослушивать сообщения в конце чтения FIFO. Вот почему последующие попытки служебных программ затем отправить сообщения по FIFO не работают.

Как вам удалось привести Debian 7 в состояние, в котором он использует System V? init инструменты, но работает другая система инициализации в то время это другой чайник рыбы. Это вполне возможно, особенно когда вы переключаетесь между системами инициализации. В действительности это не все было решено для Debian 7, и есть некоторые странные состояния, в которые может попасть система. В Debian 8 не все гладко и закончено (как есть), даже. К счастью, это был не твой вопрос. ☺

дальнейшее чтение

• Скотт Джеймс Ремнант и Джеймс Хант. initctl (8). Страницы руководства по Ubuntu.
• Роберт Миллан (август 2011). пожалуйста, подумайте о переезде /dev/initctl в /run, 638019. Система отслеживания ошибок Debian.
• Йоахим Нильссон ПРОЧИТАЙТЕ. finit.
• systemd-initctl.service. freedesktop.org.
• Роджер Ли (январь 2012). systemd: пожалуйста, используйте /run/initctl для совместимости sysvinit. 657979. Система отслеживания ошибок Debian.
• Роберт Миллан (январь 2012). 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 на OS X, а затем;
2. QEMU - простой способ эмулировать Raspberry Pi (Linux или Windows!)

Испытывая проблему (ы)

После первой загрузки 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 Похоже, чтобы решить эту проблему. Был ли это эквивалент аппаратной загрузки, которая должна решить проблему², или это была комбинация mkfifo и reboot, Я не уверен. Не мой лучший ответ, который я знаю, но, надеюсь, это поможет.

---

¹ В случае смерти ссылки слишком много информации, чтобы попытаться ее обобщить. Тем не менее, установка в значительной степени не имеет отношения к проблеме OP.

^{2 В} соответствии с невозможностью перезагрузить debian и systemd-sysv, sysvinit: проблемы с перезагрузкой при переключении между systemd-sysv и sysvinit