Bug 754242

Summary: "shutdown -r 0" "reboot" kills my RAID "can't access tty"
Product: [Fedora] Fedora Reporter: brian.broussard
Component: mdadmAssignee: Doug Ledford <dledford>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 15CC: agk, dledford, Jes.Sorensen, mbroz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-17 19:04:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description brian.broussard 2011-11-15 20:25:31 UTC
Fresh Load 
Kernel 2.6.40.6-0.fc15.i686.PAE
mdadm-3.2.2-14.fc15.i686
systemd-26-13.fc15.i686



issue a sudo shutdown -r 0 

get 
Dropping to debug shell.
sh: can't access tty; job control turned off
dracut:/#


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
yum update from test 

login in as root 
try 
 reboot 
 shutdown -r 0
 shutdown -h 0
add user 
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. 

thanks

Comment 1 Jes Sorensen 2011-11-16 09:57:45 UTC
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.

Jes

Comment 2 brian.broussard 2011-11-16 14:07:40 UTC
Hello 

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. 
from   /etc/sudoers
# %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.

Comment 3 Jes Sorensen 2011-11-16 14:33:57 UTC
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?

Jes

Comment 4 brian.broussard 2011-11-16 15:14:16 UTC
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
Thanks

Comment 5 Jes Sorensen 2011-11-16 15:21:02 UTC
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.

Comment 6 brian.broussard 2011-11-17 19:04:33 UTC
Hello 

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 

thanks again.