On Wed, 2008-05-28 at 00:02 -0500, Rubens Gomes wrote: > I have CentOS 5 (=RHEL 5). I am trying to umount the /usr in init level "1" but I cannot due to "/usr: device is busy". After "lsof" research I discoverd the following opened files used by the shell (/bin/sh -> bash).COMMAND PID USER FD TYPE DEVICE SIZE NODE NAMEsh 3180 root mem REG 8,3 56459040 199464 /usr/lib/locale/locale-archivesh 3180 root mem REG 8,3 25462 199708 /usr/lib/gconv/gconv-modules.cacheQuestions:1) How do I close/release these locale/gconv files from the sh process?2) If I cannot release the above files from the sh, is there a static version of bash or ksh that I could install/configure for the root? That is a shell that is not dynamically linked to any resources/files on the system?Having dynamically linked shell at level init 1 is *not* acceptable. The root shell should be completelly independent of any dynamic linking especially for level 1 administration. Is this a flaw of RHEL linux? I remember in Sun Solaris I used to have statically versions of ksh a nd bourne shell under the root account.Thanks.Rubens Gomes I understand the concern, but the response I have is two fold beginning with a question: Why exactly do you need to unmount /usr? A) Solaris 9 and earlier do have /sbin/sh statically linked so that it is always able to be run. Sun has seen how infrequently that comes into play and with Solaris 10. B) Linux is not Solaris. This may seem curt and I do not mean it to be so, but there are lots of differences between them. In this case the most pertinent one is recovery. Suppose you do what a friend of mine at uhacc.org did and install a bad libc. You get a brick. Hurray! You can always boot off of some other random disk and do surgery to fix the system. In my data center I have a CD envelope taped to each rack with a current version of Knoppix in it. If I F*up a clean repair environment is only a CD boot away. Should I ever find a box toasted enough to make me unmount /usr I would rather boot off of a clean source anyway.... God only knows what else is broken and could be further harmed by the boot sequence. With both A and B in line I would hesitate to call this a flaw. Pat -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
