Bug 19720
Summary: | reboot on startup while it should not be | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Michael Tokarev <mjt> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | rvokal |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-10-25 18:59:15 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
Michael Tokarev
2000-10-24 19:39:07 UTC
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. |