SuSE 8.2 Will Not Poweroff, Shutdown, Reboot, Halt...
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
SuSE 8.2 Will Not Poweroff, Shutdown, Reboot, Halt...
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.
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.
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...
# Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany. All rights reserved.
# Author: Florian La Roche <firstname.lastname@example.org>, 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
# First script to be executed, if not booting in emergency (-b) mode
# /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!)
# what to do in single-user mode
# 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
# for ARGO UPS
sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING
# getty-programs for the normal runlevels
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
1:2345:respawn:/sbin/mingetty --noclear tty1
#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:
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?