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

10763
henje

Я обновил свой сервер до Debian wheezy и поиграл с ним. Через некоторое время я захотел перезагрузить компьютер и обнаружил ошибку

shutdown: /run/initctl: No such file or directory

Я искал в Интернете и узнал, что initctl происходит от выскочки. Даже если он не установлен в соответствии с aptitude и serviceкоманда sysvinit все еще работает. Я ценю любую помощь.

4
Для меня `reboot -f` работает, но это не реальное решение ситуации. henje 9 лет назад 3
Спасибо за перезагрузку -f. Хороший совет. После дальнейшего поиска в Google, перезагрузка должна решить проблему, но это не так. Я также запустил `mkfifo / run / initctl`, который останавливает ошибку _No такой файл или каталог_, но все равно не выключает систему. Теперь я получаю `init: открытие тайм-аута / запись канала управления / run / initctl`. Я сравнил только что созданный `/ run / initctl` с тем, что на моем рабочем RPi, и они выглядят одинаково:` prw ------- 1 root root 0 января 1 1970 / run / initctl`. Greenonline 9 лет назад 0
Я чувствую, что мы находимся в одинаковой ситуации, я все это тоже попробовал, но все равно не повезло: D henje 9 лет назад 0
Я не знаю, в чем ваша проблема, но, похоже, моя проблема в том, что мой сервер виртуальный, а не управляемый. henje 9 лет назад 0
Я исправил проблему. Моя тоже виртуальная машина, использующая [qemu] (http://wiki.qemu.org/Main_Page). Greenonline 9 лет назад 0

2 ответа на вопрос

4
JdeBP

I searched on the web and found out that initctl comes from upstart.

This error is what you get from research by search engine, rather than manual page.

The name is actually /run/initctl. Upstart has a /sbin/initctl. The two are completely different things. The former is a FIFO that is used to send control commands to process #1. The latter is a program file.

Originally, (Linux's clone of) System V init would create, in process #1 at boot time, a FIFO named /dev/initctl. Programs such as telinit operated by opening that FIFO and writing messages to it that process #1 would read and act upon.

Systems such as Upstart, Joachim Nilsson's finit, and systemd provide compatibility shims that create a FIFO in /dev/initctl, listen for messages, and translate the commands from System V concepts into the finit/Upstart/systemd equivalents. So tools that expect the System V init program to be running can still open that FIFO and write commands to it. (Not all init systems provide such shims, though. And if you ask the Debian System V init people they'll tell you that this is a poorly documented internal API that programs that aren't part of the System V bundle shouldn't really be using in the first place.)

Then, a few years ago, the Debian System V init people decided that the FIFO was going to move from /dev/initctl to /run/initctl. So they changed their init to create it there, and changed all of the tools that come with their init — such as shutdown, halt, telinit, and so forth — to look for it there.

They only told the developers of one of the other systems though. So when non System V init systems are managing the system, they are still mostly providing their compatibility shim FIFOs at /dev/initctl. If one mixes a System V init tool with such a non-System V init system, then the tool will try to open the FIFO in its new location whilst the system is providing it in the old location.

The workaround should, by now, be obvious: A quick symbolic link does the trick. 

ln -s /dev/initctl /run/initctl
And it lasts until the next reboot (when presumably one has restarted the system into a saner configuration that doesn't mix init systems up, and that will attempt to make the FIFO itself). Roger Leigh, one of the maintainers of the Debian System V init package, pointed this out in 2012.

Note that it isn't really necessary to use the System V init tools, at all. The lack of a compatibility shim FIFO on many init systems is not that big a deal. systemd, Upstart, nosh, and other systems all tend to provide their own versions of tools such as halt, reboot, telinit, and so forth, anyway. These tools talk the native protocols of their respective systems and don't use the initctl FIFO at all. systemd's shims talk the relevant D-Bus protocols to process #1, directly. Upstart's shims generate the relevant upstart events, directly. nosh's shims send the relevant signals to process #1, directly.

All of that fumbling around in the other answer and the comments boils down to two points:

  • If you boot with /bin/bash as process #1, rather than some actual init system, then of course there's not going to be an initctl FIFO anywhere. As aforementioned, it's the init system that creates it. Afresh. At every bootstrap.
  • And it's the init system that responds to it. Creating the FIFO manually with mkfifo doesn't magically bring into existence the server that is supposed to be listening at the read end of the FIFO for messages. Which is why utility programs' subsequent attempts to then send messages down the FIFO don't work.

How you managed to get Debian 7 into a state where it's using the System V init tools but is running another init system at the time is a different kettle of fish. It's quite possible to do this, especially when one is in the middle of switching init systems. This really wasn't all sorted out for Debian 7, and there are some strange states that a system can get into. It's not all smooth and finished in Debian 8 (as it stands), even. Fortunately, this wasn't your question. ☺

Further reading

1
Greenonline

У меня была точно такая же проблема с raspbian wheezy, которую я использую на эмуляторе RPi на qemu . Я, кажется, решил проблему для моей конкретной установки. Работает ли это для вас - другое дело. Я надеюсь, что это так. Я буду честен и скажу, что я не уверен, в чем была проблема, или как она сама себя исправила, но я задокументировал все, что сделал, и не пропустил ни одного шага.

преамбула

Я настроил эмулированный Raspberry Pi, используя qemu, используя эти два руководства 1 :

  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 ХИП с «нормальной» загрузки, выходя из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

Похожие вопросы