|Summary:||System hangs at shutdown|
|Product:||[Retired] Red Hat Linux||Reporter:||Sammy <umar>|
|Component:||initscripts||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-02-07 21:15:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Sammy 2001-02-02 18:30:27 UTC
After the upgrade (and I was at Rawhide January 22 before) everytime I shot down the halt script seems to hang at the umount level. Here is the message I get: ..... ..... Turning off swap: [OK] umount2: Device or resource busy umount: /usr: device is busy INIT: no more processes left in this runlevel and hangs...if I do ctrl+alt+del at this stage.....I get shutdown: warning: cannot open /var/run/shutdown.pid I have tried this logged in as root from the console.
Comment 1 Bill Nottingham 2001-02-02 18:37:41 UTC
Exactly which version of initscripts do you have installed?
Comment 2 Glen Foster 2001-02-02 22:57:42 UTC
We (Red Hat) should really fix this before next release
Comment 3 Sammy 2001-02-05 23:03:12 UTC
Sorry for getting back late: I retried 5.59 and 5.60 and they both give the same error 5.55 works just fine (once you fix the network script error). After reboot I also noticed that it is always the /usr partition that it is hanging on. All other partitions (/, /boot, /var, /home, /tmp) do umount cleanly....strange. I checked /etc/mtab and all partitions/filesystems have the same properties. Also, $ cat /proc/mounts /dev/root / ext2 rw 0 0 /proc /proc proc rw 0 0 /dev/hda1 /boot ext2 rw 0 0 /dev/hda5 /home ext2 rw 0 0 /dev/hda8 /tmp ext2 rw 0 0 /dev/hda10 /usr ext2 rw 0 0 /dev/hda6 /var ext2 rw 0 0 none /dev/pts devpts rw 0 0 automount(pid416) /misc autofs rw 0 0 Could it be a problem with umount?
Comment 4 Bill Nottingham 2001-02-05 23:12:13 UTC
Blarg. Can you install lsof, copy it to /bin, and add a call to it inside the: while [ -n "$remaining" ... loop in /etc/rc.d/init.d/halt? When this is done, what processes have stuff in /usr open, and what is it that they have?
Comment 5 Harald Hoyer 2001-02-06 17:14:09 UTC
It happened to me when the module msp3400 for my Hauppage TV card is still loaded.
Comment 6 Bill Nottingham 2001-02-06 17:53:16 UTC
Um, I'm confused. Why would the module being loaded hold /usr open?
Comment 8 Sammy 2001-02-06 21:02:19 UTC
Hi!....I did the lsof thing with 5.60 and sent it into a file >>/usr/lsof.log I am attaching the file.
Comment 9 Sammy 2001-02-06 21:17:48 UTC
Created attachment 9181 [details] Now lsof is in /bin and out is /bin/lsof.log
Comment 10 Travis Shugarts 2001-02-07 01:47:29 UTC
The shell script /etc/init.d/functions is sourced into /etc/init.d/halt. Lines 23-26 in /etc/init.d/functions sets the enviroment variable LANG to whatever is in /etc/sysconfig/i18n. If LANG is defined as anything but POSIX then libraries located in /usr/lib/locale are loaded by sh. In the case of /etc/init.d/halt this will cause the /usr partition to become unmountable. My solution would be to remove the offending commands from /etc/init.d/functions, as any program that would need LANG set to something other than POSIX should have it set by it's init script.
Comment 11 Bill Nottingham 2001-02-07 01:55:26 UTC
You can't do that though; that breaks internationalization of the init scripts. halt most certainly can be special cased, though.
Comment 12 Bill Nottingham 2001-02-07 02:04:16 UTC
What does your /etc/sysconfig/i18n look like? I'm curious because we can't reproduce the same problem here; it's solved by the fact that halt (or reboot) is called with LANG unset.
Comment 13 Travis Shugarts 2001-02-07 15:40:50 UTC
My /etc/sysconfig/i18n has the following: LANG="en_US" LC_ALL="en_US" LINGUAS="en_US" I'm using initscripts-5.59-1 Yes, /etc/rc does unset LANG before it calls halt, but LANG is reset by /etc/init.d/functions when halt calls it. I think a fix could be to create a variable in halt, say NOLOCALE, then export that var before calling functions. Functions would then check if NOLOCALE is set. If it is set to yes (or something) then functions would skip over the locale stuff (or set LANG=POSIX). This way only halt and functions need to be modified and internationalization of everything else would be unaffected. Do you need internationalization for halt? If you do then the only thing I can think of would be to move the locale libs into /lib, as they are now required for startup/shutdown. Hope this helps
Comment 14 Sammy 2001-02-07 16:47:57 UTC
Funny, I was about to come to the same conclusions since the two scripts only differed in the LANG assignment. I am not an expert though, so what is the way to fix it? Mine is: # cat /etc/sysconfig/i18n LANG="en_US" LC_ALL="en_US"
Comment 15 Bill Nottingham 2001-02-07 18:01:26 UTC
The fact that it is reread in the halt script from /etc/init.d/functions is actually irrelevant; at that point the shell is already started, and it's not going to open new locale files.
Comment 16 Travis Shugarts 2001-02-07 20:17:25 UTC
Your right about LANG, but LC_ALL will load new locale files. Try typing in bash LC_ALL="de_DE" Now do a lsof and you will see that the German locale files are loaded by bash along with the ones for your default locale. I've removed the LC_ALL="en_US and LINGUAS="en_US" entries from /etc/sysconfig/i18n, and my test system is now cleanly unmounting /usr on halt. /etc/sysconfig/i18n has only one line now: LANG="en_US"
Comment 17 Bill Nottingham 2001-02-07 21:15:05 UTC
Will be fixed in kudzu-0.93-1; thanks for the idea!
Comment 18 Bill Nottingham 2001-02-07 21:15:35 UTC
Aargh, wrong open window.
Comment 19 Bill Nottingham 2001-02-07 21:22:44 UTC
Will be fixed in initscripts-5.63-1. That makes more sense. :)