я обновил свой сервер до Debian wheezy и поиграл с ним. Через некоторое время я хотел перезапустить и произошла ошибка
Kompshutdown: /run/initctl: No such file or directory
Я искал в интернете и обнаружил, что initctl исходит от upstart. Даже если он не установлен по склонности и service команда sysvinit все еще работает. Я ценю любую помощь.
3055
я искал в интернете и узнал, что initctl исходит от выскочки.
эта ошибка, что вы получаете от поисковых систем, а не руководство.
название /run/initctl. Upstart имеет /sbin/initctl. Эти две вещи совершенно разные. Первый-это FIFO, который используется для отправки команд управления для обработки #1. Последний представляет собой программный файл.
изначально, (Linux клон) System V init создаст, в процессе #1 во время загрузки, FIFO с именем /dev/initctl. Такие программы, как telinit работает, открывая этот FIFO и записывая в него сообщения, которые Процесс № 1 будет читать и действовать.
такие системы, как Upstart, Joachim Nilsson 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 люди решили, что FIFO будет двигаться от /dev/initctl в /run/initctl. Поэтому они изменили свою init создать его там, и поменяли все инструменты, которые приходят с их init - например,shutdown,halt,telinit и так далее - искать ее там.
они рассказали только разработчикам одной из других систем. Поэтому, когда не System V init системы управляют системой, они по-прежнему в основном обеспечивают их совместимость shim FIFOs в /dev/initctl. Если смешать систему V init инструмент с таким несистемным V init система, затем инструмент попытается открыть FIFO в новом местоположении, в то время как система предоставит его в старом местоположении.
обходной путь должен быть очевиден: быстрая символическая ссылка делает трюк.
ln -s /dev/initctl /run/initctlи это длится до следующей перезагрузки (когда, предположительно, один перезапустил систему в более разумную конфигурацию, которая не смешивает системы инициализации, и это будет пытаться сделать сам FIFO). Роджер ли, один из сопровождающих Debian System V
init пакет, указал это в 2012 году.
обратите внимание, что на самом деле не обязательно использовать System V init инструменты, на все. Отсутствие совместимости shim FIFO на многих системах инициализации не так уж и важно. systemd, Upstart, nosh и другие системы все, как правило, обеспечивают собственные версии инструментов, таких как halt,reboot,telinit и так далее в любом случае. Эти инструменты говорят родные протоколы их соответствующих систем и не используют initctl FIFO вообще. оболочки совместимости systemd напрямую взаимодействуют с соответствующими протоколами D-Bus для обработки #1. Оболочки совместимости Upstart создают соответствующие события upstart напрямую. оболочки nosh отправляют соответствующие сигналы непосредственно в процесс #1.
все это шарит в другом ответе, и комментарии сводятся к двум пунктам:
/bin/bash как процесс #1, а не какая-то фактическая система инициализации, то конечно там не будет to be an initctl FIFO где угодно. Как уже упоминалось выше, это система init, которая ее создает. Снова. На каждое ушко.mkfifo волшебным образом не приводит к существованию сервер, который должен прослушивать сообщения. Вот почему последующие попытки утилит отправлять сообщения вниз по FIFO не работа.как вам удалось перевести Debian 7 в состояние, когда он использует System V init инструменты но работает другая система инициализации в то время другой чайник рыбы. Это вполне возможно сделать, особенно когда один в середине переключения системы инициализации. Это действительно не все было решено для Debian 7, и есть некоторые странные состояния, в которые может попасть система. Это не все гладко и закончено в Debian 8 (как он есть), даже. К счастью, это был не ваш вопрос. ☺
initctl(8). Страницы справочника в Ubuntu./dev/initctl to /run. 638019. Система Отслеживания Ошибок Debian.debian/patches/93_run_initctl.patch. alioth.debian.org.halt,poweroff,reboot. страницы руководства systemd. freedesktop.org.reboot(8), halt(8), poweroff(8). Страницы справочника в Ubuntu.
я ровно та же проблема с Raspbian хриплым, что я бегу на эмулятор RPi на qemu. Кажется, я решил проблему для своей конкретной установки. Работает ли это для вас-другое дело. Я надеюсь, что это произойдет. Я буду честным и сказать, что я не уверен, что проблема была, или как он исправил себя, но я задокументировал все, что я сделал, и не пропустил никаких шагов.
я создал эмулированная малина Pi с помощью qemu, используя эти два руководства1:
на first загрузка 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 с" нормальной " загрузки,оставив the 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 и имя хоста, и ударил, и система перезагрузилась. Я тогда начал QEMU RPi снова с
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 казалось, чтобы решить эту проблему. Был ли это эквивалент жесткий boot, который должен решить вопрос2, или если это была комбинация mkfifo и reboot, я не уверен. Не самый лучший ответ, который я знаю, но, надеюсь, это поможет.
1 существует слишком много информации, чтобы попытаться обобщить, в случае смерти ссылки. Тем не менее, установка в значительной степени не имеет отношения к вопросу OP.
2 по данным не удается перезагрузить debian и systemd-sysv, sysvinit: проблемы при перезагрузке при переключении между systemd-sysv и sysvinit
 |  |  |  |  |  |  |  |  |  |
Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]
