On Tue, 12 Aug 1997, Peter S Galbraith wrote: > There was a discussion about this recently... So I thought I'd mention this: > This is posted on cola; looks neat to me: > <rant off> This is rediculous. Just don't install the sysv-init stuff and run a bsd init + rc.local. By the by, BSD systems do a very sysvr4 kind of modular startup these days anyway -- because its better. As far as easy to tell what's going on, just look in the run control directory for whatever run level you want to examin! You don't even need a friggin' editor! Just because linux distributions have done a piss poor job of implementing the sysvr4 startup configuration, it doesn't mean its a bad idea. We should just do it right instead of hacking sysvinit to work like an rc.local monolothic startup.
If you want to see how its supposed to work, look at Solaris 2.x, Irix 6.x, etc. I've rewritten rc to do just that somewhere, but I wound up having to undo whatever debian does _every time I added a package_! It became too much work, so I bagged it. The premise is that a run level is _clearly defined_ and managed according to a schema. Debian just shotguns links in everything that looks like a run control directory under /etc (practically). A real sysr4 rc script should run all K* scripts in a run control directory, then all S* scripts, starting with rc1.d, incrementally up to the defined run level. This means that having stuff in rc1.d and rc2.d is totally redundant. Likewise for rc2.d and rc3.d, etc. After the defined default run level is achieved, changing run levels occurs by simply running the K* scripts in the new run level, then the S* scripts. Debian currently only correctly defines rc.boot, rc0.d, rc6.d and rc1.d. the "multi-user" run levels are all defined the same. This is absurd. Having run levels defined for a specific purpose is what they're there for. Why it is we don't do that is beyond me. I can remmber having this discussion before and the conclusion was that it would be too complex to actually define run level 2 as a "multi-user network client" configuration, run level 3 as "multi-user network server" configuration and level 4 as some variation of run level 2. That would leave run level 5 for "power down" once more hardware supports it, and 7, 8, and 9 as possible variations on multi-user run levels, or "failover" run levels assuming responsabilities for a failed server somewhere else on the lan. The issue arose when package maintainers had to classify their packages as to falling into one of the categories described. Some client process are dependant on server processes, etc. These would need to be sorted out. Obviously any local services required to make a machine fit the description "multi-user network client" would need to be started by the end of run level 2. There were a couple of other gripes, but I don't remember what they were. This capability -- to define multiple possible running "states" -- has been around for a while, and its much better than MS's "dynamic" profiling. I used to have a laptop with run levels defined for "standalone", "docked", "no xdm", "NY", "HK". Using debian's scheme, I needed to have everything defined in every run level (2,3,4,7,8). In reality, I should have been able to define run level two as the default, and the others as diffs from that state. Show me how to do that with rc.local -- without hacking it to work like sysvinit. As for x86 vendors having a pow wow over how "we" should standardize differently than "real unix" systems do it, what's the point of this? This is precisely why industry leaders get annoyed with "us". Would it really be so awful to just adopt the "standards" of current commercial practice? And no, SCO doesn't count. Industry leaders currently means Solaris, HP(Hitachi)/UX, AIX, Irix, and maybe DU. <rant off> -- "Until we extend the circle of our compassion to all living things, we will not ourselves find peace" -Albert Schweitzer Richard G. Roberto -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .