Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, Dima wrote: Assuming runlevel is roughly equivalent to state, the above model is a stack of states. A state transition diagram would be a (potentially fully connected) graph of states. (Potentially) what a mess. :) I don't think so. Just because it's potentially fully connected, it's not necessary for its handling to be messy. Next question is how to define a state -- 6 basic states is what we have now. If we want more states (finer grain) our graph becomes messier. No,no. When we are talking about runlevels being a state, we should consider only the handling of state transitions. The actual graph depends on the actual usage, not anything else. And we have 9 states at least, read the init man page. Stack is a much simpler structure -- easier to implement, less bugs etc. Besides, it's almost there already. But it can be messy if you want real state machine. And you will definitely want real state machine in some cases. I myself want state machine because I make a mission critical system consisting of two machines. The system itself has to have more states, and the machines may also want to change role should some failure occur. In this state of affairs I have to link K scripts for every single service I dont't want to every single runlevel. It _is_ messy. And once more: the actual state machine has nothing to do with the init scripts, they only make up a state, and define a state transition. The state machine have to be implemented by the availability demon (coming soon to the public). --- GNU GPL: csak tiszta forrásból -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, Richard G. Roberto wrote: On Thu, 14 Aug 1997, Donovan Baarda wrote: So excuse me if I have got this wrong, but does that mean going from run level 2 to run level 7 requires running all K* then S* in run level 3, then all K* then S* in run level 4, then all K* then S* in run level 5, . all the way up to run level 7? And going from run level 4 down to 2 does the same in reverse? No. The incremental behavior is only up to the default run level. If there is none defined, you get prompted at startup for a run level and I'm not sure if the system should use the incremental method or jump right to it at that point. There seems to be confusion as to how this works. I have received two different answers from people about how this works; 1) The incremental behavior only applies up to the default run level. From there, changing run levels only runs the K* then S* scripts for the run level changed to. 2) The incremental behavior applies for all run levels and changes of run level. However, *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. [Manjo] Method 1 allows arbitary definitions of runlevels for different purposes, allowing any runlevel to have any packages running independant of what is running in any other runlevel *except up to the default runlevel*. For this to work properly for all runlevel transitions, every runlevel must have K* scripts for all packages you don't want running at that level, and S*scripts for all packages you do want running. This has the problem of potentialy running S*'s for packages already running, and K*'s for packages not running. It also begs the question; why bother with incremental running at all? Method 2 requires a strict heirachy of runlevels, with increasing numbers of packages and functionality as you go up runlevels. It ensures that S* and K* are never run out of order. However, the strict heirachy has pretty severe limitations. It is not possible to stop packages as you go up runlevels, or start them as you go down. This seems to contradict having runlevel 5 as powerdown and 6 as reboot (also, the incremental behavior would make it impossible to reboot without powerdowning first). As someone else also pointed out, a clean heirachy of runlevels with increasing functionality as you go up is not necisarily that simple. Which is a higher runlevel, an x-terminal or a web server? Do you want xdm running on your web server or apachie on your x-terminal? You only have K* scripts if you need to shut a process or server down for proper operation in the new run level (or make sure something's not running). You only have S* scripts for the stuff you need started _for that run level_. If you cock this up, you can end up having a totaly different configuration at runlevel 4 if you go to it from runlevel 2, or runlevel 3. Messy. Run level 5 isn't implemented as power down yet, but it should be. Obviously if you do an init 5, you should expect to go down. If you set your default run level to 7, you're in for a very short session ;) The 7, 8, 9 run levels are unique to linux AFAIK. They shouldn't be used as defaults for the reason's you point out. If the behavior is always incremental, then having runlevel 5 as powerdown would make it impossible to go to runlevel 6 (shutdown). What I thought would be more sensible is to know what needs to be running at each runlevel, and when you change runlevels, do a diff on the two runlevels, kill everything in the first but not in the second, and start everything in the second not in the first. This allows you to transition faster between arbitary runlevels, and avoids transitioning through runlevels you don't want to touch on the way. This is compatible with the state model, is simple to implement, and allows more flexibility than a stack of states as suggested by someone. Note that the stack of states approach is similar to method 2 above, but it could allow packages to be K*'ed on going up a level. This is more flexible than only adding packages as you go up, but it still requires you to step through each state in order. This means going through powerdown on the way to reboot, and possibly toggling packages on and off as you go. The diff method allows arbitary state transitions, without having to explicity define all the actions to perform on every possible state transition. Each runlevel defines a state, listing all the packages that must be running at that level. The actions to perform on transitioning from one state to another are determined by comparing the two states. Only the minimum number of actions required are performed on any state transition, and undesirable states can be skipped. Again, changing run levels after the default has been reached just runs the K* then S* scripts for that run
Re: /etc/init.d structure [long rant]
On Fri, 15 Aug 1997, Dima wrote: [EMAIL PROTECTED] wrote: Manoj Srivastava writes: *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? Simple and elegant, but not very flexible. How about a state machine approach? Assuming runlevel is roughly equivalent to state, the above model is a stack of states. A state transition diagram would be a (potentially fully connected) graph of states. (Potentially) what a mess. :) Depends on how you do it. A fully connected graph of states doesn't need to have each possible state transition manually defined. All you need is definitions of each state, and the state transition actions can be automaticly determined by comparing the two states. Next question is how to define a state -- 6 basic states is what we have now. If we want more states (finer grain) our graph becomes messier. Why would you want more than 6? Even if you do, you only need to define the additional states (specify what should be running in each state). Also, runlevels _are flexible. Nobody can force me to start networking daemons at RL 2 -- I can bloody well start them from ip-up when I ring my ISP, at whatever runlevel I happen to be then. (In practice I don't care: when I don't need networking daemons, they waste about $0.5 worth of my swap partition. Big deal). This is a different thing all together. What you are doing is saying that runlevels are not flexible enough to handle your networking daemon requirements, so you'r gonna do it manualy. You are just saying that they are flexible because you don't have to use them. If you let user similarly customize the states, you _will end up with a fully connected graph for STD -- definitely a mess. (One program implementing a complex state machine is sendmail, BTW.) Stack is a much simpler structure -- easier to implement, less bugs etc. Besides, it's almost there already. Yes, it is simpler, and it is almost there already, but; 1) is it the standard way of doing it, or are we inventing yet another way of doing it? 2) regardless of whether it is a standard, it has limitations, and can we live with those limitations? ABO -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, E.L. Meijer (Eric) wrote: [...] Manoj Srivastava wrote: You are hereby excused. *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? There is one thing that I dont see yet. There might be a necessity to introduce parallel routes, e.g. you would want to have a runlevel that starts xdm, and one that starts networking deamons for machines that actually are on a network. But there is no intrinsic order between these things. My machine at home is not connected to any network, which means that certain daemons are not necessary, even if I do want to run X. Other people may want to connect to the network without having to go through a runlevel that starts xdm. Now how is this tackled? Eric Meijer True this would take some planning. Agreed it has it limitations. However, it doesn't even work this well currently, at least in Debian GNU/Linux. Our current approach is just plain broken. Even if you go through the trouble of fixing it, it re-breaks with every package installation (that installs a start/stop script). I would just like it to work as expected and we can go from there. Adding enhancements to the system while keeping it backward compatable is attractive, but not as easy as it sounds. Cheers, -- 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] .
Re: /etc/init.d structure [long rant]
On 14 Aug 1997 [EMAIL PROTECTED] wrote: Manoj Srivastava writes: *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? Simple and elegant, but not very flexible. How about a state machine approach? Considerably more flexable than rc.local, or anything else to date. The key is having explicit control -- no magic. Having an optional package that replaced the sysvinit startup with a state machine (whatever that is) is fine by me. But I still think we should fix what's broke. In time, I'm sure that Linuxconf will be able to handle multiple running states with some kind of menu selectable state at startup or something at some point. Perhaps this would be the alternative of choice. Cheers, -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED]Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- -- 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] .
Re: /etc/init.d structure [long rant]
In message [EMAIL PROTECTED] you wrote: On Fri, 15 Aug 1997, Dima wrote: Also, runlevels _are flexible. Nobody can force me to start networking daemons at RL 2 -- I can bloody well start them from ip-up when I ring my ISP, at whatever runlevel I happen to be then. (In practice I don't care: when I don't need networking daemons, they waste about $0.5 worth of my swap partition. Big deal). This is a different thing all together. What you are doing is saying that runlevels are not flexible enough to handle your networking daemon requirements, so you'r gonna do it manualy. You are just saying that they are flexible because you don't have to use them. What I meant was, let's say on my box I have runlevels 0 - 2 for powerdown (you're quite right about that not belonging in rl 5, btw), halt and reboot, rl 3 = single-user, 4 = multi-user and 5 = multi-user with xdm running. I'm not concerned with, e.g. networking daemons. A person configuring web/mail/newsserver would be concerned with the order in which daemons are started, and s/he would edit rls 4 - 6 accordingly. S/he doesn't care about xdm. On, say, a router programs running at rls 4 - 6 will be different again. What remains is the order in which various programs are started/killed; I think that can easily fit into a stack-like thingy (or a state machine, for that matter). We don't know which exactly various programs they'll happen to be on a given machine; we can, however, provide a reasonable, easy to modify default. Anyway, I'd prefer any (open would be nice) standard, as long as it's supported by at least 3 - 4 different unices. As long as it's not a single program group called startup... :) -- Dimitri --- By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meet the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or $500, whichever is greater, for each violation. (Solicited advertisements huh? and other such can be sent to emaziuk at curtin dot edu dot au) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
On Wed, 13 Aug 1997, Richard G. Roberto wrote: 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: [snip] 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. So excuse me if I have got this wrong, but does that mean going from run level 2 to run level 7 requires running all K* then S* in run level 3, then all K* then S* in run level 4, then all K* then S* in run level 5, ... all the way up to run level 7? And going from run level 4 down to 2 does the same in reverse? Doesn't this mean that with something that has an S* in runlevel 3,5,7 and a K* in 2,4,6, that it will be started, stopped, started, stopped... all the way through? What about going through a runlevel 5 which is for power down? What I thought would be more sensible is to know what needs to be running at each runlevel, and when you change runlevels, do a diff on the two runlevels, kill everything in the first but not in the second, and start everything in the second not in the first. This allows you to transition faster between arbitary runlevels, and avoids transitioning through runlevels you don't want to touch on the way. This sort of scheme can be implemented in a variety of ways, including config files, or S* symlinks in rcn.d directorys (no need for K* anymore). I don't want to introduce yet another way of doing it, but it just seems to make more sense to me. [snip] 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. why not just have the postinst script ask the user what runlevels do you want this package to run at? and provide sensible defaults. That frees the package maintainer from deciding what to clasify the package as, and allows the user to have his own customized runlevels. [snip] 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. I agree that an x86 only view of the world is stupid. hardware platforms are becoming more meaningless all the time. However, I do belive that it is worth thinking of free standards independantly of comercial standards. Sure we can adopt the commercial standards if they are good enough and we are free to do so, but if they suck we should go ahead and make our own. The free software community is large enough now that we can make our own standards, and even sometimes make the comercial world follow us. This is becoming even more important now that the comercial guys are making open standards in a way that ensures they have a technical edge and is hard for the competition to implement. ABO -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
I agree that an x86 only view of the world is stupid. hardware platforms are becoming more meaningless all the time. However, I do belive that it is worth thinking of free standards independantly of comercial standards. Sure we can adopt the commercial standards if they are good enough and we are free to do so, but if they suck we should go ahead and make our own. The free software community is large enough now that we can make our own standards, and even sometimes make the comercial world follow us. I'd like to second this. Standards are definitely worth having. But not when they consist of inferior technology handed down to us from commercially-dominated organizations in which we have no representation. The nice thing about standards is that you can pick and choose which ones you are going to support. (I have no opinion on the /etc/init.d stuff though) Cheers, - Jim pgpOu2IS76psH.pgp Description: PGP signature
Re: /etc/init.d structure [long rant]
Hi, Donovan == Donovan Baarda [EMAIL PROTECTED] writes: Donovan So excuse me if I have got this wrong, but does that mean Donovan going from run level 2 to run level 7 requires running all K* Donovan then S* in run level 3, then all K* then S* in run level 4, Donovan then all K* then S* in run level 5, ... all the way up to run Donovan level 7? And going from run level 4 down to 2 does the same Donovan in reverse? Donovan Doesn't this mean that with something that has an S* in Donovan runlevel 3,5,7 and a K* in 2,4,6, that it will be started, Donovan stopped, started, stopped... all the way through? What about Donovan going through a runlevel 5 which is for power down? You are hereby excused. *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? Donovan why not just have the postinst script ask the user what Donovan runlevels do you want this package to run at? and provide Donovan sensible defaults. That frees the package maintainer from Donovan deciding what to clasify the package as, and allows the user Donovan to have his own customized runlevels. I think that punting this decision on to the user is bad design. Firstly, installing a large number of packages may well overwhelm a novice, secondly, there are ordering requirements between packages (potentialy) that the user may not be aware of, and thirdly, debugging and customer support are going to be a nightmare, with every system different from every other system. There _is_ a way of doing this style of rc right (though it would generate *lots* of debate on debian-devel [yummy]), and I think the devopers *can* get to a consensus on what belongs at each run level -- (we did get to agree on the required, important, optional and extra categories, didn't we?) manoj who would be interested in hearing more about how other unices got rc.? right. -- In Western terms, love is like an extended software Q.A. suite. True love is like a final acceptance test. But one has to be willing to take bug fixes and work-arounds; otherwise, the software is never done. The Usenet Oracle Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
[...] Manoj Srivastava wrote: You are hereby excused. *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? There is one thing that I dont see yet. There might be a necessity to introduce parallel routes, e.g. you would want to have a runlevel that starts xdm, and one that starts networking deamons for machines that actually are on a network. But there is no intrinsic order between these things. My machine at home is not connected to any network, which means that certain daemons are not necessary, even if I do want to run X. Other people may want to connect to the network without having to go through a runlevel that starts xdm. Now how is this tackled? Eric Meijer -- E.L. Meijer ([EMAIL PROTECTED]) | tel. office +31 40 2472189 Eindhoven Univ. of Technology | tel. lab. +31 40 2475032 Lab. for Catalysis and Inorg. Chem. (TAK) | tel. fax+31 40 2455054 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, Donovan Baarda wrote: So excuse me if I have got this wrong, but does that mean going from run level 2 to run level 7 requires running all K* then S* in run level 3, then all K* then S* in run level 4, then all K* then S* in run level 5, . all the way up to run level 7? And going from run level 4 down to 2 does the same in reverse? No. The incremental behavior is only up to the default run level. If there is none defined, you get prompted at startup for a run level and I'm not sure if the system should use the incremental method or jump right to it at that point. Doesn't this mean that with something that has an S* in runlevel 3,5,7 and a K* in 2,4,6, that it will be started, stopped, started, stopped... all the way through? What about going through a runlevel 5 which is for power down? You only have K* scripts if you need to shut a process or server down for proper operation in the new run level (or make sure something's not running). You only have S* scripts for the stuff you need started _for that run level_. Run level 5 isn't implemented as power down yet, but it should be. Obviously if you do an init 5, you should expect to go down. If you set your default run level to 7, you're in for a very short session ;) The 7, 8, 9 run levels are unique to linux AFAIK. They shouldn't be used as defaults for the reason's you point out. What I thought would be more sensible is to know what needs to be running at each runlevel, and when you change runlevels, do a diff on the two runlevels, kill everything in the first but not in the second, and start everything in the second not in the first. This allows you to transition faster between arbitary runlevels, and avoids transitioning through runlevels you don't want to touch on the way. Again, changing run levels after the default has been reached just runs the K* then S* scripts for that run level. We do that part right already. We just don't define the run levels correctly. Until we do, its pointless to consider a functional rc script since the run levels will be identicle. This sort of scheme can be implemented in a variety of ways, including config files, or S* symlinks in rcn.d directorys (no need for K* anymore). I don't want to introduce yet another way of doing it, but it just seems to make more sense to me. Well, if I run something in run level 3 that conflicts with something in run level 4, I need to stop the service in conflict before the run level 4 process tries to start. That's why I can define K* scripts. This works like the diff you mentioned. [snip] 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. why not just have the postinst script ask the user what runlevels do you want this package to run at? and provide sensible defaults. That frees the package maintainer from deciding what to clasify the package as, and allows the user to have his own customized runlevels. Flexibility is always good, and I support having a mechanism to allow users to customize this easily (admintool? package configuration tool?), but there should be functional defaults shipped with the system (for everything IMHO) so that users don't _have_ to muck around with that if they don't want to. [snip] 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. I agree that an x86 only view of the world is stupid. hardware platforms are becoming more meaningless all the time. However, I do belive that it is worth thinking of free standards independantly of comercial standards. Sure we can adopt the commercial standards if they are good enough and we are free to do so, but if they suck we should go ahead and make our own. The free software community is large enough now that we can make our own standards, and even sometimes make the comercial world follow us. This is becoming even more important now that the comercial guys are making open standards in a way that ensures they have a technical edge and is hard for the competition to implement. This argument is only viable about 4% of the time its used. The rest of the time its just another artificial obstacle to progress. I can remember working for a DEC var a few years ago when
Re: /etc/init.d structure [long rant]
Manoj Srivastava writes: *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? Simple and elegant, but not very flexible. How about a state machine approach? -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED]Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
[EMAIL PROTECTED] wrote: Manoj Srivastava writes: *Nothing* has an S* in more than one level. A package is meant to be at a certain run level and higher. A level 3 package is started at run level 3, killed in run level 2, and at *no* other level. See how this works? Simple and elegant, but not very flexible. How about a state machine approach? Assuming runlevel is roughly equivalent to state, the above model is a stack of states. A state transition diagram would be a (potentially fully connected) graph of states. (Potentially) what a mess. :) Next question is how to define a state -- 6 basic states is what we have now. If we want more states (finer grain) our graph becomes messier. Also, runlevels _are flexible. Nobody can force me to start networking daemons at RL 2 -- I can bloody well start them from ip-up when I ring my ISP, at whatever runlevel I happen to be then. (In practice I don't care: when I don't need networking daemons, they waste about $0.5 worth of my swap partition. Big deal). If you let user similarly customize the states, you _will end up with a fully connected graph for STD -- definitely a mess. (One program implementing a complex state machine is sendmail, BTW.) Stack is a much simpler structure -- easier to implement, less bugs etc. Besides, it's almost there already. -- Dimitri emaziuk at curtin dot edu dot au, if you're replying to --- a Usenet posting Avoid reality at all costs. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
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] .
Re: /etc/init.d structure [long rant]
[ ... ] 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. I always used to think it was me who didn't get it. I customized one runlevel to run without xdm. I used this runlevel to upgrade XFree86, so that if anything screwed up, I would not have xdm continously restarting a bogus X setup. This can be very annoying and very hard to escape, I know from experience. However, after the configuration script is done, it starts xdm as if no runlevels exist (I guess it only checks /etc/X11/config). I agree fully that a proper implementation of sysvr4 would be a Good Thing. Eric Meijer -- E.L. Meijer ([EMAIL PROTECTED]) | tel. office +31 40 2472189 Eindhoven Univ. of Technology | tel. lab. +31 40 2475032 Lab. for Catalysis and Inorg. Chem. (TAK) | tel. fax+31 40 2455054 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
E.L. Meijer (Eric) wrote: [ ... ] ... I always used to think it was me who didn't get it. I customized one runlevel to run without xdm. I used this runlevel to upgrade XFree86, so that if anything screwed up, I would not have xdm continously restarting a bogus X setup. This can be very annoying and very hard to escape, I know from experience. However, after the configuration script is done, it starts xdm as if no runlevels exist (I guess it only checks /etc/X11/config). I agree fully that a proper implementation of sysvr4 would be a Good Thing. Ditto. I always wandered why there are all those redundant links in rc?.d dirs, and why I can't easily make a runlevel for xdm I used to have in Slack. -- Dimitri emaziuk at curtin dot edu dot au, if you're replying to --- a Usenet posting Avoid reality at all costs. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/init.d structure [long rant]
Please note, the current unstable distribution is planning on changing the runlevel setup. To the best of my knowledge, the actual runlevel setup has not been decided upon yet. Unstable will not be released as stable for quite some time though, so don't hold your breath (last guess I heard was around december or january). Brandon -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
