Red Hat Bugzilla – Bug 19720
reboot on startup while it should not be
Last modified: 2014-03-16 22:16:58 EDT
This affects all versions of initscripts. No, this is _not_ a util-linux (aka sulogin) bug. When something wrong in /etc/rc.d/rc.sysinit (like unable to mount filesystem(s), unable to start raid etc etc), rc.sysinit calls sulogin and reboot after that. Among the inconsistent messages (rc.sysinit says that system will reboot, sulogin says "press ^D for normal startup), that just should NOT happen. System should NOT reboot in this case (if user wants to reboot it, he can issue halt/shutdown manually from sulogin's shell). I just don't know why redhat placed that reboots in rc.sysinit. If user can correct a problem, system can continue to boot. Moreover, it is not fatal if failure occured during some operations, _especially_ when single boot was wanted. For up to now, there was no problem for me, just an annoyance. But now I have strange situation. My sulogin by some reason wan't to check password (it says "login incorrect" each time). This is not a bug in sulogin but probably a my fault, but does not matter here. Ok, now I have just unusable system that can be repaired using rescue disk or by plugging harddrives to another machine. But the only problem I have is an extra raid partition on another two disks that I forget to clear when removed that disks (that was just an experiment with raid; I put two more disks and set up a raid partition on them; after that I turned off the machine and removed the disks; and now I can't boot, and that disks also unavailable). Ok, I'm able to resolve the problem. That will cost me some time at evening, as I need to plug the disks to another machine that is busy at worktime, and also I need to find appropriate scsi wires (or even maybe to move scsi controller to that machine too). But just after that I will remove those ugly and _stupid_ (yes) reboots from /etc/rc.d/rc.sysinits. And the same I propose to Redhat. BTW, some time ago I always removed that reboots, but after some upgrades that was enouth -- it is a pain to edit rc.sysinit after every upgrade on every machine.
The rc.sysinit is a big one now, with many optional "services" started from it. Why not use init.d scripts for that services, with low ordered numbers? Want to initialize usb -- ok, run init.d/usb; raid -- ok, init.d/raid; want to mount filesystems -- fine, init.d/mountfs. Place them in appropriate order, and that's all. Why not put all the init.d/* to rc.sysinit after all?! :) With current rc.sysinit style, last possibility seemed to be appropriate... With rc.sysinit split there will be easier to repair the system, at least to see if the failed component of it can be started next time (for my situation, when I got a shell prompt, I would like to issue something like 'service raid start' to check if my raid will start next boot; when I remove reboot from sysinit, that will be my real step before hitting ^D at sulogin shell). And also -- I know at least one possible cause of calling reboot. It is a stupid/beginner user that aren't able to start appropriate service (see above also). With this, that may be really better to not to allow system to boot further. But I can't just agree with this. Ok, if this is a case (i.e. reboot to save a beginner user from seeng tons of error messages), than I can suggest at least to have some flag (e.g. /noreboot file) to serve as reboot stopper. But probably this is also not a solution (at least if this flag will be removed), since root can be read-only at this stage. But the best solution will be just to remove reboot completely. Error messages are not a big issue...
What do you think about this: o have a directory, say, /etc/rc.d/sysinit.d, similar to rc[0-9].d. This directory should be processed by rc.sysinit the same way that other rc\d.d processed by rc (note that sysinit.d combines init.d that does not processed by any script _and_ rc[0-9].d that gives an order of executions). The only exception to rc?.d is that rc.sysinit checks return value from each sysinit.d/* script and executes the following sequence if that return != 0: sulogin ask "reboot? [Y/n]" reboot IF answer was yes It (rc.sysinit) should remember all entries from sysinit.d before an error occured, and on reboot it should execute them in reverse order (with argument 'stop'). o place usb, raid, filesystem checks, hdparm tuning etc to that sysinit.d directory in appropriate order, and make that scripts parts of corresponding package (raid for raidtools for example). Seemed to be appropriate.
And oh yes, I found why my sulogin wan't to execute shell. In bash-2.04-8, there are lines in /etc/bashrc: ... # Don't do anything if /usr is not mounted (i.e. /usr is a separate # partition and we're run by fsck) [ -d /usr/bin ] || exit 0 ... Here, /usr is not mounted, so bash just exited... This bug was corrected in new bash package.
Hey, you had the pinstripe bash package installed. ;) Yes, we're looking at reorganizing rc.sysinit. Marking this as an enhancement request for now.
Ohha... :) This isn't an enhancement really. I said about a bug (I considered it so, may be I'm wrong) in rc.sysinit -- it should not reboot the system in case of some trouble, or at least it should provide an option to prevent this reboot. This is _not_ an enhancement request. And I doesn't understand _why_ it reboots? (I already have one possible answer above, but still not shure). At least all other unices that I've seen does not have this reboot. Sulogin asks for a password, and after that system continued boot process. Yes, there may be a lot of error messages, many services can be not started etc, but system may come to some useful state. The unices that I told about here are solaris, hpux and sco. The rest was about a ways of resolving that bug, together with some other things/suggestions... But let's go with "enhancement" state if you like so. The only thing that I should remember from now on is that I need to download the _source_ rpm for initscripts and remove that reboots before it builds if I will need to upgrade it... :( BTW, what's "pinstripe"? I know that this was some prerelease, but don't remember the release number... Is that was 6.2?
Pinstripe was the 7.0 beta. The bash package from it had this 'feature'.
After discussions with people here, this won't be done. The reboot is there to make sure that all FS structures are completely re-read in cases of *massive* filesystem changes; we've had people have corruption happen before when they didn't reboot.