On Fri, Jul 06, 2001 at 05:49:10PM +0100, Eric E Moore wrote: > Dave> Worse, though, is the case of a binary-only package which makes > Dave> assumptions about running services based on runlevel. When it > Dave> breaks because of customized runlevels, the admin _can't_ fix it > Dave> except by going back to the LSB-defined scheme. > > Certainly, this is bad, however I imagine that altering the LSB > specification to forbid this sort of idiotic behavior,
Idiotic? Perhaps. But I've seen its like many times in the years I spent as a developer. Not only could I name programmers who would take the easy way out, even if they knew they would have to go back and fix it later (in hopes of being able to evade the fix by whining about how it's too much trouble for too little benefit), I could also name managers who would order their underlings to do it the wrong way for the illusion of expediency. That sort of thing is plenty common in the world of commercial software. In any case, even if making assumptions based on current runlevel is explictly forbidden by the standard, it will be done unless that specific point is regularly tested for compliance by the certifying body. Unfortunately, I would expect it to be a low priority for testing, as it would only cause trouble on "non-compliant" systems. > and saying that > the runlevels are defined for the sole purpose of determining which > runlevels to insert boot scripts into, and that relying on checking > the runlevel is an error, would be well-recieved, whereas just > chucking the whole thing, will not. <cynicism> Of course it wouldn't be well-received to suggest that the standard be changed to make admins' lives easier at the cost of making things a little more difficult for commercial developers. Which of those two groups is writing the standard? </cynicism> > I disagree. Starting X may involve starting multiple services, xdm, > xfs, it's certainly possible you don't want sound daemons running, > unless you've switched into "workstation mode". On the flip side, you may have a server (I know that I've got one) which doesn't run X itself, but still wants xdm, xfs, etc. running so that other machines on the network can attach to them. If you can't know that a priori, why should the standard make assumptions about it? > Certainly, grouping > together networking services (potentially a great many services) into > a runlevel makes sense. Certainly, a network daemon should not be > installed into a runlevel which doesn't ifup any interfaces. Yes, but, unlike xdm, this is an easy one to test for. Just look at ifconfig to see if any non-loopback interfaces are configured or route to see if any routes are defined. Or, again, don't make any assumptions - a standalone machine may want apache running so that, e.g., dwww can make man pages available through netscape even if there aren't any other machines to talk to. > Certainly, an LSB 2 with an entirely new > system for handling init, that has full dependency and pseudo-package > (gdm/xdm/etc) support would be an exciting thing. Indeed it would, but it dependency on a specific configuration of runlevels can be removed without requiring the full dependency information. The init scripts should have a pretty good idea of what they need to work and can look to see whether those things are running and exit if they aren't, just like the standard Debian init scripts verify that the daemon's binary exists before trying to execute it. Yes, if I decide to create a new zdm, I may have to modify a script to tell it that zdm is an acceptable substitute for xdm, but, IMO, that's a small price to pay for the assurance that, if I rearrange my runlevels, (or, the next day, I write a replacement for init that either doesn't use runlevels or allows an infinite number of them) I won't have to worry about software malfunctioning or not installing properly because I'm in violation of LSB's assumptions about how I use my machine. > Dave> `/etc/init.d/xdm stop|start` might > Dave> call for a little more typing than `init 3|5`, but it's hardly > Dave> difficult. And, to me at least, `xdm stop` obviously means > Dave> "shut xdm down", while `init 3` has no readily apparent > Dave> relationship to X or xdm unless you're bringing outside > Dave> knowledge with you. > > Agreed. Assuming, of course, you don't run xfs or rplay, or anything > else you want running with X. In which case it does make sense to > group those things together. The only mechanism we have now in init, > is runlevels. You make a good point. Perhaps the better avenue, then, would be to work up a standard for defining groups of services which can be started up and shut down together, rather than trying to standardize on a 'one size fits all' set of runlevels. It might even be easier, although I can already see a few problems that would have to be dealt with. Just to throw in a little history here (and risk incurring the wrath of the Open/Free Software equivalent of Godwin's Law), the first thing I learned when I encountered Microsoft Access was that it made writing certain types of applications incredibly easy. The second thing it taught me was that, to achieve that ease, it made a lot of assumptions about what the user wanted to do and those assumptions made it very difficult (sometimes bordering on impossible) to get it to do anything else. Since then, I've learned that it is only very rarely that you can make specifically foreseen tasks easier without making unforeseen tasks more difficult as a side effect. I believe that any attempt to assign standardized meanings to runlevels falls into this category: It makes it easier to setup a system that does normal things in a normal configuration and easier for third parties to set up software for installation on these normal systems. But not all systems are normal and I don't think that any standard should be written which makes those systems non-compliant by default. Thus I maintain that Debian has the right idea: The distro makes no assumptions about how you use your runlevels. If you want them all to be identical, that's fine. If you want to configure them so that networking is only enabled in runlevel 8 (yes, according to man init, "Runlevels 7-9 are also valid, though not really documented") and network services are only started in runlevel 1, go right ahead; Debian doesn't care. (Well, OK, Debian does make one assumption: Newly-installed services are installed in all runlevels, which is equivalent to assuming that, if you install something, you want to have it running. Seems reasonable to me, particularly given that the alternative minimal assumption is to not run it by default.)
