5

I updated my server to Debian wheezy and played around with it. After a while I wanted to restart and encountered the error

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

I searched on the web and found out that initctl comes from upstart. Even though it is not installed according to aptitude and the service command of sysvinit still works. I appreciate any help.

  • 4
    For me reboot -f works, but it is no real solution to the situation. – henje Mar 8 '15 at 15:44
  • Thx for the reboot -f. Good tip. After further googling, a hard reboot is supposed to fix the issue, but it hasn't. I have also run mkfifo /run/initctl which stops the No such file or directory error, but still doesn't shut the system down. I now get init: timeout opening/writing control channel /run/initctl. I have compared the /run/initctl just created, with the one on my working RPi, and they look identical: prw------- 1 root root 0 Jan 1 1970 /run/initctl. – Greenonline Mar 8 '15 at 16:24
  • I feel like we're in the same situation, I tried all of these as well and still no luck :D – henje Mar 8 '15 at 16:47
  • I do not know what your problem is but mine seems to stem from the fact, that my server is virtualized and not a managed one. – henje Mar 8 '15 at 18:19
  • I have fixed the issue. Mine is a virtual machine too, using qemu. – Greenonline Mar 8 '15 at 18:31
5

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

I was having exactly the same issue with a raspbian wheezy that I am running on a RPi emulator on qemu. I appear to have solved the issue for my particular setup. Whether it works for you is another matter. I hope that it does. I will be honest and say that I am not sure what the issue was, or how it fixed itself, but I have documented everything that I did, and not missed out any steps.

Preamble

I had set up an emulated Raspberry Pi using qemu, using these two guides1:

  1. Installing QEMU on OS X, and then;
  2. QEMU – Emulating Raspberry Pi the easy way (Linux or Windows!)

Experiencing the issue(s)

Upon first booting qemu with the command (note the use of 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

once the system had booted, I found, like the OP, that the halt command would not run, instead giving the error:

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

I then ran (courtesy of I got a error flag "init: /dev/initctl: no such file")

mkfifo /run/initctl

which stopped the No such file or directory error, but still didn't shut the system down, instead giving the error

 init: timeout opening/writing control channel /run/initctl. 

I compared the /run/initctl just created, with the one on my working RPi, using ls -l /run/initctl and they looked identical:

prw------- 1 root root 0 Jan 1 1970 /run/initctl

Possible solution

I pressed on with the guide's steps regardless, after a reboot -f. Now this next step is where the fix occurred I believe. I started the qemu RPi with a "normal" boot, leaving out 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 booted into the raspi-config. I merely changed the pi user's password and the hostname, and hit and the system rebooted. I then started the qemu RPi again with

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

It booted into the tty login screen. I logged in, ran startx. After X started I ran sudo shutdown -h now. It shutdown and halted as expected, without any init: errors.

Conclusion

The booting of the (virtual) device without the init=/bin/bash appeared to fix the issue. Whether this was the equivalent of a hard boot which is supposed to fix the issue2, or if it was a combination of the mkfifo and the reboot, I am not sure. Not my best answer I know, but hopefully it will help.


1 There is way too much info to attempt to summarise, in case of link death. However, the setup is largely irrelevant to the issue of the OP.

2 According to can't reboot debian and systemd-sysv, sysvinit: problems rebooting when switching between systemd-sysv and sysvinit

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.