After the recent announcement that the FreeBSD boot scripts in /etc have been replaced with the next generation version imported from NetBSD, I’ve wanted to learn more about the new system, but wasn’t able to find much info. However, I managed to find a great document called “The Design and Implementation of the NetBSD rc.d system” by Luke Mewburn of Wasabi Systems, Inc.
The document explains in detail, what are the reasons for the new system, it’s strong and weak points and it’s differences to other init systems. Although the document is focused on the original NetBSD implementation, the vast majority of information applies to FreeBSD as well.
this resembles sooo much the slackware init.. (Sysvr3 if I recall corect)
Its not just the way Slack does it, it seems simular to the way all Linux distro’s handle boot up… funny really, FreeBSD is always looking more and more like Linux it seems to me…
I suppose its a good thing for FreeBSD though, I fail to see any real advantages though, other then they can work on each script seperatly…
Oh well, I never much liked FreeBSD, but if they keep becoming more and more Linux like… well I guess I will likely start to appreciate it more…
FreeBSD has always seemed very basic in most areas, now all they need to do is follow some kind of file system hirarichal (sp) stamdard, and maybe I will use it again…
From what I can remember from reading slackware’s website, that particular distribution’s init script is based on BSD. Many other linux distribution’s also are based on BSD’s style of init scripts. This is why you see such a similarity. Also to note, slackware, at least according to the book on their website, uses a combination of System V and BSD-style, though it leans more towards BSD.
No, it isn’t like most Linux distro’s. Each daemon has a start/stop script like SysV (in /etc/rc.d), but daemons are “controlled” using /etc/rc.conf instead of symlinks. E.g. if you want to run postfix you’ll need to add POSTFIX=yes to /etc/rc.conf
I don’t really see what the GPL penguin has to do with any of this…
thats one think i prefered in the linux startups… maybe /etc/rc.conf is “simpler”… its not in the long run… there is no logic… if a new daemon is installed how do you know what DAEMON=yes to add to /etc/rc.conf? there is no standard naming scheme. is it MAIL=yes, SENDMAIL=yes, MYMAILDAMON=yes?
i could look it up. but i doubt there will be a standard logical naming scheme. and would people stick to it?
i like the fact that i can look in /etc/rc.d and especially /erc/rc.d/init.d/ and find
(i) all that can be started up and shiut down, giving me
a snapshot of the available damons, and
(ii) give me a pretty standard way of starting, stopping,
and restarting these using path/damon
start|stop|restart … the code itself abstracts away
the details of kills, kill -HUPs and anything else.
plus, as far as i know (again i could look it up, but its not obvious from traversing the filesystem) the i snot finer-grained control over run-levels which can be useful.
the first time i came across a difference was back in the old days when i often did a /etc/rc.d/init.d/network restart, or ipsec restart, or named restart…. now, on a BSD system i have to look it up… is it named – HUP? is it xfs -rehash? give me /etc/rc.d/init/damon restart anyday!
having read the NetBSD article… i’m very very happy… one of my biggest gripes about BSD has gone! vive la netbsd!
I think tat SCO can sue FreeBSD team also, because it is almost equal to Unix System V, a intelectual property of SCO today…
I am just kidding… 🙂
SCO must die with Microsoft and the business pratices of most american software companies…
I don’t see where is the similarity with all the linuxes.
We don’t get a number for the bootstrap.
Just slack has a rc.d and no runlevels-named files
Look up the history of the BSDs. All of the legal claims against them concerning the original UNIX code were settled long ago.
FreeBSD has always seemed very basic in most areas, now all they need to do is follow some kind of file system hierarchy standard, and maybe I will use it again…
FreeBSD already follows some kind of file system hierarchy standard. The FreeBSD one.
“FreeBSD has always seemed very basic in most areas, now all they need to do is follow some kind of file system hirarichal (sp) stamdard, and maybe I will use it again…”
Um, it DOES follow a standard. If anything, it seems to follow it far more strictly than many of the Linux distros I’ve seen. The fact that it isn’t the LSB one is no real reflection on them.
Its not just the way Slack does it, it seems simular to the way all Linux distro’s handle boot up… funny really, FreeBSD is always looking more and more like Linux it seems to me..
Umm, no… Slackware uses BSD’s idea of this. and.. No, it’s not similar to Linux’s way..
Oh well, I never much liked FreeBSD, but if they keep becoming more and more Linux like… well I guess I will likely start to appreciate it more.
Can you give us the some good examples of it?
FreeBSD has always seemed very basic in most areas, now all they need to do is follow some kind of file system hirarichal (sp) stamdard, and maybe I will use it again…
Please, get your fact first before you open your mouth. I can see that you are total know nothing about BSD at all.
man hier will give you the standard file layout that FreeBSD uses.
Why is it that whenever there is anything related to BSD, we gets posts about how Linux is better in this way and that? It seems like most of these folks are often off based about their facts.
In reply to “hardwired /etc/rc.conf – and how i’m now happy!” How hard is it to type issue /etc/rc.d/{name of service} start|stop|restart?
Give up. If it isn’t covered in fluffly penguin mascots it doesn’t register on their radar.
The link talks a lot about fine grained control over the order Daemons are started. How about the other way and do what OS X does and allow spawning of multiple daemons concurrently? Cut the startup time a bit.
…the next generation version imported from NetBSD, I’ve wanted to learn more about the new system, but wasn’t able to find much info
uh?
NetBSD documentation (with links to two another articles, one of them is the one you mention here):
http://www.netbsd.org/Documentation/rc/
http://www.daemonnews.org/200108/rcdsystem.html
http://www.mewburn.net/luke/papers/rc.d.pdf
excelent manual pages:
http://man.netbsd.org/cgi-bin/man-cgi?rc+8+NetBSD-current
http://man.netbsd.org/cgi-bin/man-cgi?rc.subr+8+NetBSD-current
http://man.netbsd.org/cgi-bin/man-cgi?rc.d+8+NetBSD-current
http://man.netbsd.org/cgi-bin/man-cgi?rcorder+8+NetBSD-current
http://man.netbsd.org/cgi-bin/man-cgi?rc.conf+5+NetBSD-current
and of course, the sources itself:
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.subr
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.conf
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/
http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/rcorder/
i am sorry but your “argument” simply doesn’t hold water..
While I didn’t actually read the article, I was amazed by the “wasn’t able to find much info”. Anyway, here’s what I think is quite a lot of info:
http://www.netbsd.org/Documentation/rc/
A few other points:
Its not just the way Slack does it, it seems simular to the way all Linux distro’s handle boot up… funny really, FreeBSD is always looking more and more like Linux it seems to me…
I really don’t see the resemblance on the way Linux handles booting.
First, Net and FreeBSD’s new system (still) doesn’t have such runlevels as the Linux systems usually do. Second, none of the Linux systems use anything like the “rcorder” tool, which dynamically at boot time checks in which order the services need to be started. And last, if a service should not be started, the service script need not be moved away from /etc/rc.d: the configuration knob in /etc/rc.conf is just turned of.
thats one think i prefered in the linux startups… maybe /etc/rc.conf is “simpler”… its not in the long run… there is no logic… if a new daemon is installed how do you know what DAEMON=yes to add to /etc/rc.conf? there is no standard naming scheme. is it MAIL=yes, SENDMAIL=yes, MYMAILDAMON=yes?
How come there’s no logic? If I have “/etc/rc.d/postfix”, “/etc/rc.d/sendmail” and “/etc/rc.d/mymaildaemon”, to make one of those start when the system is started, I put “postfix=YES”, “sendmail=YES” or “mymaildaemon=YES” to “/etc/rc.conf”. There is a standard (though not enforced) way: the name of the controlling variable is the same as the script name.
So I can check available services just by “ls /etc/rc.d”.
As a Slack user, I feel I can comment with some certainty on the Slackware rc system.
From my understanding, for a normal runlevel 3/5 startup, it processes /etc/rc.M, which is mainly lines like this:
if [ -x /etc/rc.d/rc.mydaemon ]; then
. /etc/rc.d/rc.mydaemon
fi
You can manipulate the order from there, and to disable a daemon, you just remove the executable permission from it.
Gentoo is the one with dependency-based init scripts, not slack.
just run:
/etc/rc.d/[script] rcvar
it will tell you what variables the script uses, whether they are enabled/disabled.
additionally, all system (not the ones which come with pkgsrc packages or are locally created by the administrator himself) scripts/variables are documented in /etc/defaults/rc.conf (NetBSD), where the defaults for them are set.
please read the document first, it describes it pretty clearly.
I found the link very useful. I can use it as a reference for FreeBSD-5.x.
And yes gentoo’s way of init’ing and also the way portage is designed were heavily inspired on NetBSD’s way of doing things. That’s well known and documented. Must be why I found it really bearable 🙂