Date: Sat, 26 Apr 1997 21:45:07 -0500 From: Chris Csanady <ccsanady@nyx.pr.mcs.net> To: patl@Phoenix.volant.org Cc: David Nugent <davidn@unique.usn.blaze.net.au>, Jaye Mathisen <mrcpu@cdsnet.net>, "Jordan K. Hubbard" <jkh@time.cdrom.com>, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. Message-ID: <199704270245.VAA08465@nyx.pr.mcs.net> In-Reply-To: Your message of Sat, 26 Apr 1997 12:42:35 -0700. <ML-3.3.862083755.5758.patl@asimov>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Perhaps this comes down to personal preference, but I've had
>> considerably more years experience in SysV than BSD, and I by
>> *far* prefer the BSD approach.
>
>Yes, it does come down to personal preference. I have many more
>years with various flavors of BSD; but the rc.d/init.d system
>is one of the few places where I think Solaris2 is a clear win
>over BSD.
I think it is more a case of functionality, rather than personal
preference. With the rc.d/init.d approach you have more modularity,
and the ability to start/stop random packages in a consistent way.
There is also a single standard place that a vendor can throw a
startup script in--this is a good thing.
>> Runlevel issues aside, I've found the SysV approach no simpler
>> than BSD - in fact, the exact opposite. Since you've given
>> Solaris ("Symlink City") as an example, I can't guess why you'd
>> find it easier. Yuck!
>
>Would hard links make you happier? Solaris2 certainly goes
>overboard on symlinks; but in this case I think they are the
>right way to go.
No. And no.. Although the init.d idea is good, implementing it
as a set of runlevel dirs with hoards of symlinks is a bit ugly.
It also does not address the basic issue of package dependancies.
What it comes down to is that it does not buy us enough over the
current scheme to make most BSD people happy. If someone were
to *implement* a elegant solution that addresses these problems,
people would be more receptive than to the fundamentally flawed
SysV mechanism..
>> Spreading out startup/shutdown scripts into the filesystem is
>> bogus, imho. The *general* approach is ok, but rc.d/init.d with
>> runlevel dirs with symlinks just makes the whole mess
>> unmanageable. A simple flat file with a list of sub-scripts to
>> run and in which order would be so much simpler - text editors
>> are usually somewhat more usable than a cli and the eye can more
>> easily detect errors.
>
>I find it much -more- manageable. And I -really- like knowing
>that packages can install a startup script without attempting
>to edit any of my startup files.
This is really nice..
>The rc.d/init.d directory provides a place for all of the startup
>scripts to live, under very descriptive names. Possibly including
>standard scripts for services that are not enabled on the system.
>The rc?.d directories provide a simple mechanism to specify which
>ones will be run and in what order. (The order is provided by the
>two-digit prefix on the link. Links with the same prefix may be
>run in any order.)
What does the rc?.d buy us again? And the two-digit prefix? These
are no more than a hack aimed at solving the dependancy problem--and
they only solve the ordering part too. I think multiple
configurations could be better served than dirs full of symlinks as
well.
>From the administration point of view, you are mostly interested
>in the rc.d/init.d version. That is the one that you invoke to
>manually start/stop/restart a service. That is the one that you
>view or edit if you want to see or change exactly what happens on
>service start/stop/restart. You only look in the rc?.d directories
>to ensure that the service is listed; and properly sequenced. And
>you can do that with a simple ls. (Use -l if you need to ensure
>that it is actually linked to the right script.) It's simple,
>elegant, and clean. (I'm slightly amazed that it made it into
>Solaris2 without a load of additional cruft.)
Personally, for the ability to seperate and start/stop services, I
think I could live with it the way it is. However, I would like
to see a mechanism to cleanly handle dependancies, and this does
not cut it.
--Chris Csanady
>And like it or not, FreeBSD does have at least two run levels.
>(Three if you count 'halted') The ability to automatically and
>cleanly start/stop services when switching between single and
>multi-user modes would be a big win. (For that matter, the
>ability to go from multi back to single without a reboot would
>be a win.)
>
>
>
>
>-Pat
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704270245.VAA08465>