Red Hat Bugzilla – Bug 754242
"shutdown -r 0" "reboot" kills my RAID "can't access tty"
Last modified: 2011-11-17 14:04:33 EST
issue a sudo shutdown -r 0
Dropping to debug shell.
sh: can't access tty; job control turned off
Target Dell Optiplex 990 Intel Matrix RAID
Do y'all test against real hardware because in less that 10 mins after a load it happens....
here is how I test
load with a kickstart file
yum update from test
login in as root
shutdown -r 0
shutdown -h 0
add user to sudoers
user1 ALL=NOPASSWD: /sbin/shutdown
as root reboot
login as user
issue a sudo shutdown -r 0
most of the time the first try fails.
if the system does not comeback up power off then back on and you will have this failure.....
Please let me know I will test I have 9 i7 machines on my burn in rack to test with.
Yes we do indeed test on real hardware, however adding a user to sudo
in order for the user to be able to call shutdown -r 0 isn't the most
common nor recommended usage case.
Does this problem still occur under Fedora 16?
On a side note, you really would want x86_64 on there to avoid the
system using bounce buffers constantly when running the i686 kernel.
I ask about hardware because we can not reproduce the issue using VBox or VMware, only on the targets.
what would your commendation be for a non-administrative user to reboot / shutdown a system that does not operate a windows manager? Sudoers file has a commented line that allows all users to issue a reboot / shutdown this is not acceptable for as as it is not in compliance with our security plan toallow everybody to shutdown/reboot. But if you uncomment that line and allow users same issue.
# %users localhost=/sbin/shutdown -h now
Testing in F16 has Not reproduce the issue, but there is an issue with the box stopping the process and a hard power off required. not sure if that helps or hurts. Bug https://bugzilla.redhat.com/show_bug.cgi?id=752593
Can not move the x86_64 third party components will not move and have not replaced them all as of yet. Stuck with i386 tree only.... We are pushing to try to get there.
Note sure what to do today we have been shipping i7 machines which required me to move away from FC11 (were going to update all filed systems to FC15 but have stopped) and did not see this issue until we YUM a production box to fix a different issue and started seeing this RAID problem..... we are doing some funny things right now in our build process to get the set of packages we need to run but if a field machine is YUMed they will pretty much lose some data. Not good I understand.
So your recommendations would to move to x86_64 and not let users reboot only root or process running with hight enough privileges.
If you really wish for all users to be able to reboot the system you could
simply suid the /sbin/shutdown binary - still I would not recommend this,
just as I wouldn't recommend what you are doing.
How is your system configured? Are the user's home directories located on
the RAID device? is / on the RAID?
Yes "/" down is on the raid.
So what is the method for rebooting a box as a non root user?
Yes adding s bit to the shutdown it what most people state, but that allows all ... just trying to follow good layered security for hipaa. Which requires a user to admin certain parts of the box without access to others.
I am calling all my vendors today and see about fc16 with x86_64
well if it works for root to do the shutdown, it might work for you to
let the user execute 'su -c /sbin/reboot' through sudo.
My guess is that something goes wrong because it is unable to unmount the
raid because something through the chain of the sudo call keeps some user
file descriptor open on the raid.
The problem with IMSM RAID is that the metadata is managed through mdmon,
so as long as the RAID is read-write, you cannot shutdown mdmon, and allow
for a clean reboot.
thanks we will be moving to Fedora 16 and dealing with upstream issues the RAID support seams better can not reproduce the issue in Fedora 16