Re: init.d, rc0.d, ... rc6.d
at some point around 12 Jan 1998 07:57:06 -0600 [EMAIL PROTECTED] mentioned: Sen Nagata writes: what kind of advantages does this kind of approach have compared to having a single file for each run level (or even one file for all runlevels) describing which scripts to run (as well as the order to run them in)? The present system is safer and easier to automate. If you screw up editing the single file you may cause everything in the file to fail: that's true. in general this is the case if, for a given program (or a set of programs being managed by a single configuration file), one edits 'the-currently-used' configuration file directly, right? if one were to edit a copy of a configuration file (a 'candidate configuration file') and then perform renaming of files (i think qmail uses a similar technique for reliability), that's safer right? it seems like this kind of feature could be built into editors (or added as an extension) -- so you specify which configuration file you'd like to update, the editor creates another file which you edit first, and then the editor performs the 'reliable' updating for you. anyway...i didn't want to make a point about editors, just a point about the process of altering configuration files. wouldn't it make sense to have something that provides more reliable/safe altering of configuration files (perhaps incorporating a mechanism similar to what is suggested above)? you may not even be able to boot. point well-taken :-) The present system just requires that you create some links. That is easy to do with a script, and if it fails only the service being added is affected. that's true. is there already some administrative command one can use to easily enable/disable a service? i know it is possible to write scripts to do this for various services...but perhaps there is already some existing method? -sen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: init.d, rc0.d, ... rc6.d
In article [EMAIL PROTECTED], Sen Nagata [EMAIL PROTECTED] wrote: is there already some administrative command one can use to easily enable/disable a service? i know it is possible to write scripts to do this for various services...but perhaps there is already some existing method? update-rc.d Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed [EMAIL PROTECTED] | awake all night wondering if there is a doG -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
init.d, rc0.d, ... rc6.d
hello- i've been wondering what the advantages and disadvantages are w.r.t. organizing the run-level changing/initialization scripts in the current manner. right now there are a number of scripts stored in init.d which are referenced by symbolic links from each of the rc*.d directories, right? what kind of advantages does this kind of approach have compared to having a single file for each run level (or even one file for all runlevels) describing which scripts to run (as well as the order to run them in)? besides having to 'lock' and parse a file describing what is needed for a single run level (which it seems could be dealt w/ by providing adequate routines that everyone uses), what are other demerits to taking the 'single-file' approach? (leaving out the fact that if one were to switch to such a scheme existing code might need to be modified) -sen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: init.d, rc0.d, ... rc6.d
Sen Nagata wrote: what kind of advantages does this kind of approach have compared to having a single file for each run level (or even one file for all runlevels) describing which scripts to run (as well as the order to run them in)? There's not much difference, really, though the current way is more standard. Take a look at the file-rc package, that sets up debian to act the way you want, with a single config file replacing the symlinks. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: init.d, rc0.d, ... rc6.d
Sen Nagata writes: what kind of advantages does this kind of approach have compared to having a single file for each run level (or even one file for all runlevels) describing which scripts to run (as well as the order to run them in)? The present system is safer and easier to automate. If you screw up editing the single file you may cause everything in the file to fail: you may not even be able to boot. The present system just requires that you create some links. That is easy to do with a script, and if it fails only the service being added is affected. -- 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: init.d, rc0.d, ... rc6.d
-BEGIN PGP SIGNED MESSAGE- Regarding Re: init.d, rc0.d, ... rc6.d of 9:04 PM -0800 1/11/98, Joey Hess wrote: Sen Nagata wrote: what kind of advantages does this kind of approach have compared to having a single file for each run level (or even one file for all runlevels) describing which scripts to run (as well as the order to run them in)? There's not much difference, really, though the current way is more standard. Take a look at the file-rc package, that sets up debian to act the way you want, with a single config file replacing the symlinks. No, DON'T use file-rc, it has some serious bugs (http://www.debian.org/Bugs/db/pa/lfile-rc.html). - -- Joel Espy Klecker Debian GNU/Linux Developermailto:[EMAIL PROTECTED] http://www.espy.org/http://www.debian.org/ -BEGIN PGP SIGNATURE- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNLpiSwoYIlYX1XaBAQFTHwP+OlBojlDwOwGZNucXQfKAHzuglsswemSg ZPZZy2m+W7X1da1B2hE4QbAL9ziriPBVKrqAHUjEy9/cixnH9mm/nFgrwQk7WM+a 9GmE0e7VQkmG3gCxFrn5V7bBE588eL7p0VzwfyxufvmCEGciFODpA/RKZovABmRx kPhIVFTb3xE= =Qd3E -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
