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?

4
  • 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/. Commented Aug 17, 2018 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 Commented Aug 17, 2018 at 12:21
  • 1
    If the questioner were running systemd the right thing to do would be to forget about runlevels. Commented Aug 17, 2018 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 Commented Aug 18, 2018 at 9:37

1 Answer 1

-1

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

1
  • there was many more use cases for telinit or interacting with init in general than dropping into runlevel X. as for busybox/openrc, you don't have numbered levels, which saves you from bad implementations like RHELs so called Sys-V init, but you still do have at least 3 distinct runlevels. No matter if you get there with telinit or not. since your link list is, say, focussed on a certain group and time period, I can just encourage you to try out unix on some winter evening so you'll be a bit more knowledgeable than the people whose information you trusted to be complete. Commented Sep 10, 2024 at 21:01

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.