So, I go to install QMail on the virtual server and it gets to a part where it needs to HUP init. I end up seeing this message:
init: timeout opening/writing control channel /dev/initctl
Hmm, ok, weird, but no problem - I'll just reboot.
# reboot
shutdown: timeout opening/writing control channel /dev/initctl
Uh. Okay. Well I really just need it to reload inittab, so, I'll just:
# telinit 3
telinit: timeout opening/writing control channel /dev/initctl
Ok. Now I'm aggrivated.
# kill -HUP 1
kill 1: No such process
Uh!?!?!?!?!?!? Alright, screw you anyway...
# unlink /dev/initctl
# mknod -m 0400 /dev/initctl p
# reboot
shutdown: timeout opening/writing control channel /dev/initctl
...riiiiiight. So. Anyway. Here's the answer:
# reboot -f
And for a moment there, I thought I wasn't in charge.
:)
I Can't Live Without It!
9 comments:
hi,
I have found this post helpful. Thanks
I ham experiencing a problem with a server not responding to "shutdown -h 0" command sent remotely.
I started using strace to expòre in detail for finding a solution, but It was more simple.
So thanks for "reboot -f".
So in conclusion the moral of the story is that: thaking a look to common commands is goog for saving time.
by
pajeco
Thanks for the helpful hint. It's saved my bacon on more than one occasion.
However, I'm curious as to the cause of this. Do you have any sense as to why this starts happening?
Thanks.
Hi Kristofer, no I don't know why it happens. I've only seen this problem on a single machine running Virtuozzo, so I assume the admins misconfigured something.
Pajeco - that's right :) I hadn't known there was a "force" flag for reboot until that day.
Just FYI, and for the info of anyone else seeing this, I've got this suddenly on my debian etch box. I _do_, however, have a proper Init process running as process 1, but quite a few (mainly defunct) processes running (2760, I make it). Perhaps this is some problem with abnormally high PIDs.
Thanks for the post, reboot -f let me shut down relatively cleanly.
Ran across this on a CentOS box - one of DOZENS with the same setup in our colocation center with nothing done different than a plain vanilla install and yum update.
Unless the distro released something that broke this today.
Odd - thanks for the informative website and fix!
John C. Young
Managing Director
Internet Gateway of South Beach
http://www.igsobe.com
Excellent tip! I had a remote Debian upgrade from 4 to 5 that went fine with the exception of being able to reboot it afterwards. This took care of it, thanks !!
Hello, I've found your solution useful; I'm trying to shut down my Asus EeePC 1000H (on Xandros) via ssh and got this error message
However, can you please suggest a way to shut down the system in a clean way, not to reboot it ?
Best regards,
Răzvan
Try this:
poweroff -f
or
shutdown -f
Post a Comment