0

I wasn't aware of the telinit command and I've tried to use it without any good result.

Below my command

telinit 1

I obtain the following error:

timeout opening/witing control channel /dev/initctl

The obtained strace doesn't help me 

...
rt_sigaction(SIGALRM, {0x11de0, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={3, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
open("/dev/initctl", O_WRONLY)          = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
sigreturn() (mask [QUIT])               = -1 EINTR (Interrupted system call)
write(2, "telinit: ", 9telinit: )                = 9
write(2, "timeout opening/writing control "..., 53timeout opening/writing control channel /dev/initctl
) = 53
exit_group(1)                           = ?
+++ exited with 1 +++

What does it mean?

andrew
  • 11
  • If you are running systemd on your system, use systemctl get-default and systemctl set-default to change run levels. Run levels that can be set can be seen in usr/lib/systemd/system/. – Raman Sailopal Aug 17 '18 at 12:06
  • I'm not using systemd (I'm using busybox init). Furthermore my primary goal is to be able to enter in single user mode – andrew Aug 17 '18 at 12:21
  • 1
    If the questioner were running systemd the right thing to do would be to forget about runlevels. – JdeBP Aug 17 '18 at 14:42
  • Thanks for the link but, as written, systemd supports a sort of backward compatibility and hence some programs like telinit still work well. In my case I'm using the busybox init and it doesn't have the runlevel concept. I don't think it is correlated to my error but I'm not so expert and I need advices from someone more expert than me – andrew Aug 18 '18 at 09:37

1 Answers1

0

Forget about runlevels.

Yes, it the same answer as for systemd.

BusyBox's own init program does not have a concept of runlevels in the first place. This is in the BusyBox doco. There is no run level 1 to command changing to. Using telinit with actual BusyBox init is simply wrong.

When using telinit with some other toolset's system manager running as process #1, it is still overwhelmingly wrong. On systemd operating systems, runlevels are "obsolete"; they do not exist on systems managed by many other toolsets (from the nosh system-manager through Gerrit Pape's runit-init to initNG); and it is only really van Smoorenburg init, Joachim Nilsson's finit and Upstart that have the mechanism at all.

Note that the telinit program has to match the toolset that is actually being used at the time for the system-manager program. There are lots of telinit programs from different toolsets. Some expect a FIFO in /dev/initctl. Some expect a FIFO in /run/initctl. Some speak different protocols over their FIFOs, and the van Smoorenburg init protocol is considered private anyway by its developers. Many do not even use a FIFO at all and are shims around mechanisms native to the toolset, such as the nosh telinit which is a shim around system-control, the Upstart telinit which emits Upstart events, and the systemd telinit which is its systemctl program by another name. And even for those that do use a FIFO there's the matter of there needing to be a server, which also has to match the running system manager, running and listening on those FIFOs.

All of this to enable people to preserve the learned habits of running a telinit command.

Forget about runlevels, and if you have not already got into the habit of using telinit (or, worse, init as a command), it is better not to learn it in the first place.

Further reading

JdeBP
  • 68,745