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
/run/initctl. So they changed their
init to create it there, and changed all of the tools that come with their
init — such as
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
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
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. ☺