Alright…here’s one for you:

I’ve been happily dual-booting SuSE 8.2 Professional and XP Home Edition for the past few months with no problems other than those of my own making. I’m not completely wet behind the proverbial ears (~3 years of “tinkering” experience) but neither am I the smartest kid on my block where Linux is concerned.

I prefer to start X manually from the command line, so I always boot into runlevel 3 by default (changed this in inittab, etc.) – hence, my usual method for rebooting the system involves logging out of KDE (taskbar or Ctrl-Alt-Del), wait for the CLI, then Ctrl-Alt-Del to bounce the machine (yes, it’s mapped to “shutdown –r now”). This method has always successfully rebooted the machine; additionally, all other related commands (“shutdown –h now”, “poweroff”, “init 6”, “reboot” etc. as root) have always functioned properly.

As you may have guessed from the subject of this post, the problem is this: several days ago, I went through my standard reboot regimen and watched all the daemons scroll away as usual, right up until the message “Sending all processes the TERM signal…” appeared. Then the system stopped responding. I waited patiently for about five minutes, tried the power button with no success, and killed the entire machine at the main switch.

Since this occurrence, I have had exactly the same result each time I have tried to halt/shutdown/poweroff/reboot the system (as root and otherwise). The system becomes unresponsive, but not in any way that I’ve seen before: I can still Alt-F2 my way to a new console, Num Lock/Caps Lock toggle their respective LED’s, and a Ctrl-Break will give me back a user prompt. However, no other keyboard input is recognized (can’t login as root on the new console, can’t “su” from the recovered user prompt, agitated Ctrl-Alt-Del’s aren’t productive, and so on).

The only changes that were made to the system immediately prior to the new behavior were a couple YOU updates (pine and ssh as I recall). No new hardware was added, no new software was installed, I didn’t go playing with the user security settings in YaST2. I’d go modprobing for ACPI/APM but the system was handling all this beautifully before; BIOS settings look fine (and of course, XP is still handling these power events as normal).

Regrettably, I’m not near the machine and so will not be able to provide logs and such until later this evening.

Anyone seen this/have any ideas? Am I missing something stupid/obvious? I’m not averse to reinstalling the system (I lose a few hours, big deal) but I’d like to know why this functionality seems to have “spontaneously” disappeared. The fscking chest wound every time I boot is also a real pain.

Hi,
You know more about linux than I do, so I will not pretend that I can help. I have done a little playing with some of the commands that you mention , plus killall5. Except for my machine spitting up all over the floor a couple of times, I can not really duplicate the problem, and I am not really sure that I want to. When I get nervous enough to back up my home directory, it is getting plenty serious.
Since I am not certain how the shutdown process actually works, I am guessing that for some reason the killall5 signal is killing the shell that it is running in too, but I have no idea why.
Please post your inittab file so I will have something to look at, and I will go away quietly.
Good luck.

Hey, please don't go tossing your machine on my account...while I appreciate any help I can get, far be it from me to intrude on another's system stability.

As far as my knowing more than anyone else, I'd be the last to press that point at the moment...after all, I'm the one with the hinky machine. I also am uncertain about how the shutdown process operates (and to be honest, don't even know which log I should be examining for trouble).

As requested, here's the inittab file currently in use; as mentioned above, I believe the default runlevel 3 is the only non-standard configuration here.

Thanks for having a look...
__________________________________________________

#
# /etc/inittab
#
# Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany. All rights reserved.
#
# Author: Florian La Roche <feedback@suse.de>, 1996
#
# This is the main configuration file of /etc/init, which
# is executed by the kernel on startup. It describes what
# scripts are used for the different run-levels.
#
# All scripts for runlevel changes are in /etc/init.d/.
#
# This file may be modified by SuSEconfig unless CHECK_INITTAB
# in /etc/sysconfig/suseconfig is set to "no"
#

# The default runlevel is defined here
id:3:initdefault:

# First script to be executed, if not booting in emergency (-b) mode
si::bootwait:/etc/init.d/boot

# /etc/init.d/rc takes care of runlevel handling
#
# runlevel 0 is System halt (Do not use this for initdefault!)
# runlevel 1 is Single user mode
# runlevel 2 is Local multiuser without remote network (e.g. NFS)
# runlevel 3 is Full multiuser with network
# runlevel 4 is Not used
# runlevel 5 is Full multiuser with network and xdm
# runlevel 6 is System reboot (Do not use this for initdefault!)
#
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
#l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# what to do in single-user mode
ls:S:wait:/etc/init.d/rc S
~~:S:respawn:/sbin/sulogin

# what to do when CTRL-ALT-DEL is pressed
ca::ctrlaltdel:/sbin/shutdown -r -t 4 now

# special keyboard request (Alt-UpArrow)
# look into the kbd-0.90 docs for this
kb::kbrequest:/bin/echo "Keyboard Request -- edit /etc/inittab to let this work."

# what to do when power fails/returns
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
pn::powerfail:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# for ARGO UPS
sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING

# getty-programs for the normal runlevels
# <id>:<runlevels>:<action>:<process>
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
#
#S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102

#
# Note: Do not use tty7 in runlevel 3, this virtual line
# is occupied by the programm xdm.
#

# This is for the package xdmsc, after installing and
# and configuration you should remove the comment character
# from the following line:
#7:3:respawn:+/etc/init.d/rx tty7


# modem getty.
# mo:235:respawn:/usr/sbin/mgetty -s 38400 modem

# fax getty (hylafax)
# mo:35:respawn:/usr/lib/fax/faxgetty /dev/modem

# vbox (voice box) getty
# I6:35:respawn:/usr/sbin/vboxgetty -d /dev/ttyI6
# I7:35:respawn:/usr/sbin/vboxgetty -d /dev/ttyI7

# end of /etc/inittab
__________________________________________________

Although I said I would go away, I do have another comment or two.

Do not be concerned that I will destabilize my machine. As the youth of today say "If you aren't living on the edge, you are taking up space". ( At least, that is what I think they are saying, who can tell what they are actually mumbling. )

I changed my inittab file to look as much like yours as possible. It made no difference that I could tell.

I have been unable to find a log that tells what is going on at shutdown. I keep seeing references to /var/log/wtmp , but it is in binary, and that is not my first language.

I tried creating my own log. I typed the command <script> , and then <shutdown -r now> . It did create a file called typescript, but it was empty.

ONLY if you decide to reinstall, and have nothing to lose, you might try editing the /etc/init.d/rc file, and uncomment the line that says "debug=echo". During shutdown, this kind of shows you what is being done, but it drops me into a maintainence prompt where the shutdown command no longer works (reboot and halt do work)
As I said, do this only if you give up trying to fix the problem, and decide to reinstall. I have determined that when you start changing these files, you are kicking it where it is real soft.

Thanks for all the effort. I also went hunting for some sort of shutdown log last night, but wasn't able to find anything that looked promising. I checked my /etc/init.d/halt.local file (the last thing run before "Sending all processes the TERM signal...") for any erroneous instructions, but this is empty as well.

I'll keep the debug option in mind for the imminent reinstall...I figure if nothing in the way of a solution has made itself apparent in the next few days, this incident gets filed under "Huh: That Was Weird" and the system will be fdisked/reinstalled.

Again, thanks for your assistance. Anyone else have any ideas before I nuke this thing from orbit?