Hello experts,

I'm faced with a challenge, hopefully one of you is able to help me with. From time to time, when booting a Linux machine here at work, one of the boot processes hangs leaving the machine inaccessable. A reboot is basically the only option we have then.

What we'd really like is there is a way so we can access the machine in it's hanging state so we can see what's causing it and thus resolving the issue. The hanging process is early in runlevel 3.

For the complete configuration, these are all virtual machines running WindRiver Linux 4.2 on a Red Hat Enterprise Virtualization platform.

Any help will be greatly appriciated.
Louis

doesnt the boot.log have that info? have you checked that?

Well, not real time info on running processes etc. Just to make things more clear, it's typically one of the init scripts that hangs, and just blocks the whole machine from continuing the boot process. The machine in itself is working. We'd like to debug it in the state it's in.

Unofrtunately, there often isn't a good way to get to a shell early in the boot process since the virtual consoles aren't brought up until getty, mingetty, or the like are spawned by init, usually at or near the end. The better option would be to figure out what service is hanging. If possible, you should put a timeout in the init script that starts it that will cause it to exit if the service has not started. This page describes the basics of how to do this within the init script. If the script is hitting some error condition though, it might be best just to test on that directly.

1 members found this post helpful.

Thanks, I'll have a look at the handling timeouts in the init script. That may be quite useful anyway.

Having said that, would it be possible to make init spawn getty etc as one of the first things? Like that we could have the desired console access.

In theory it should be possible, but I'll admit that I don't know how to do it. On older init systems (pre upstart/systemd/init-flavor-of-the-week) this was controlled by lines in /etc/inittab, so I'd start there. Otherwise, consult the documentation for the init system that you happen to be using.

1 members found this post helpful.

you COULD edit the boot entry to add init=/bin/bash to the kernel options, thiss will dump you to a bare minimum root shell (with the volumes mounted read only), from there you can run
to mount the / partition read/write and temporarily disable the buggy init script, or at least read the log files to see what's going wrong with the init script and modify it as necessary

note, doing this will leave the machine in a bare-bones state with no services such as networking running

1 members found this post helpful.

Hi,

Thanks for the tip. I tried it, but I'm afraid this is not what I'm looking for. The machine will drop into a shell straight away. But I'm looking for a possibility to get console access the moment the script is haning. So that's somewhere in runlevel 3.