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
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
-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
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.
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 curren
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
6 matches
Mail list logo
