Re: etc/rc.d things...
Cyrille Lefevre wrote: Non-centralized configuration is frowned upon. Having to find which file has something, or having to read through multiple files to understand how the system is configured is a disadvantage wrt to the present system. not so difficult if a command do that for you. (show, change, start and stop) Commands limit you in awkward ways. Hell, AIX has commands to do anything with the configuration you might want, but that has not prevented people from hating it... :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On Mon, 10 Jul 2000, Mikel wrote: Kelly Yancey wrote: How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... I like it. It's clean and simple, almost to the point of being elegant. But why bother adding rc?.d if you are going to right it to handle s or k then the present home should be fine, no? It was a reference to how SysV organized it's rc scripts. SysV implements 'run-levels' for which there is a rcX.d for each run-level. The startup/shutdown scripts for a run-level are executed at transitions between levels. In any event, it was a poor attempt at humor on my part. Don't go down this road, read the archives to see why (search for init and runlevels). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Cyrille Lefevre wrote: http://www.freebsd.org/~dfr/devices.html off topic. M... I must have copied the wrong link, then... http://www.freebsd.org/~eivind/newrc.html well. what about a mix of the SystemV approach (ala HP-UX) and the IRIX one (using something like chconfig). HP-UX : /sbin/init.d/script start_msg|stop_msg|start|stop (FMPOV, there isn't not enough possible choises, such as status, restart, config, command, etc.) /sbin/rc[S0-5].d/[SK][0-9][0-9][0-9]script linked to /sbin/init.d/script ^^ This is confusing and difficult ot manage. /sbin/rc (+ /sbin/rc.util) sources /etc/rc.config then runs /sbin/rc?.d startup files /etc/rc.config.d/services are configuration files (ala bourne shell). Non-centralized configuration is frowned upon. Having to find which file has something, or having to read through multiple files to understand how the system is configured is a disadvantage wrt to the present system. /sbin/rc.config sources /etc/rc.config.d configuration files. /usr/sbin/ch_rc is not so easy to use to modify /etc/rc.config.d/services. IRIX : oops, don't remember how works startup scripts. I just remember me configurations files : /sbin/chconfig [on|off] service or something like that. (don't remember if it's possible to change options through chconfig, but I guess no). /etc/config/services enable or disable services. /etc/config/services.options just contains arguments to services. so, a mix of both w/o the levels stuffs + a /etc/rc.default.d (a synonym to /etc/defaults/rc.conf but in separate files between HP-UX and IRIX configuration files) would be a begining. It would be a waste of time. Without the levels, we are gaining nothing, and we loose in additional useless complexity. Alas, "levels" is a half-assed solution, because the states in which a system can be in are in a graph. The above proposal doesn't have an ink of a chance. Please, read Eivind's page, and read the numerous previous post on this topic. and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. effectively, the last one is interresting. a major problem w/ this one is the use of "perl" which is not available a boot time since it is located in /usr. I'm sure it can be easily done as a C program. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
"Daniel C. Sobral" [EMAIL PROTECTED] writes: Cyrille Lefevre wrote: HP-UX : /sbin/init.d/script start_msg|stop_msg|start|stop (FMPOV, there isn't not enough possible choises, such as status, restart, config, command, etc.) /sbin/rc[S0-5].d/[SK][0-9][0-9][0-9]script linked to /sbin/init.d/script ^^ This is confusing and difficult ot manage. I'm just explaining HP-UX and IRIX implementations for someone who don't know them. /sbin/rc (+ /sbin/rc.util) sources /etc/rc.config then runs /sbin/rc?.d startup files /etc/rc.config.d/services are configuration files (ala bourne shell). Non-centralized configuration is frowned upon. Having to find which file has something, or having to read through multiple files to understand how the system is configured is a disadvantage wrt to the present system. not so difficult if a command do that for you. (show, change, start and stop) Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On Mon, 10 Jul 2000, Mike Meyer wrote: :Daniel C. Sobral writes: : Mike Meyer wrote: : The multiple levels are there to deal with changes in state. In BSD, for : instance, we have single user/multi-user. A number of other variations : can exist, both in heavy duty servers where you might want to bring : certain services down for upgrade and then back up, and "desktop" : machines, such as notebooks where you can be stand-alone, docked into : different networks (eg. home/work). : :I'm familiar with why mutliple levels exist. I've never run into a :system that had a real use for more than three run levels - powered :off, maintenance, and up - though I've not dealt with Some of the machines I work on have three useful multi-user states. Runlevel 2 is plain-old multi-user mode, where filesystems are mounted, and the normal collection of services (mail, telnetd, ftpd, etc) are running. Run level 3 adds the DBMS, run level 4 adds the database dependent application. :P.S. - anyone else remember rc.single? Anyone care? Haven't seen one since Ultirx. shudder. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Kelly Yancey wrote: On Sat, 8 Jul 2000, Mike Meyer wrote: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... I like it. It's clean and simple, almost to the point of being elegant. But why bother adding rc?.d if you are going to right it to handle s or k then the present home should be fine, no? Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Network Operations Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard
Re: etc/rc.d things...
Please Please Please _Dont_!!! I dont know if someone is yoking, my english is not up to that :( I tried to secure a Solaris machine and hated the whole setup. I't have some good things but i take the simple rc.conf mechanism every time! /Johan On Mon, 10 Jul 2000, Mikel wrote: Kelly Yancey wrote: On Sat, 8 Jul 2000, Mike Meyer wrote: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... I like it. It's clean and simple, almost to the point of being elegant. But why bother adding rc?.d if you are going to right it to handle s or k then the present home should be fine, no? Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Mike Meyer wrote: Yes, that's correct. And yes, not all is bad in SysV. In particular, having a directory where you can find scripts to stop (and restart) subsystems is very nice. I think the multiple levels (rc?.d) is a bit of overkill. Either the system is up (meaning everything is turned on), or it's down, and the sysadmin who brought it down can start the subsystems s/he needs. Having a single init.d to look in for those things helps in that process. The multiple levels are there to deal with changes in state. In BSD, for instance, we have single user/multi-user. A number of other variations can exist, both in heavy duty servers where you might want to bring certain services down for upgrade and then back up, and "desktop" machines, such as notebooks where you can be stand-alone, docked into different networks (eg. home/work). Thing is, SysV does it in a very ugly way, and not flexible enough either. This has been talked to death. Look at these: http://www.freebsd.org/~dfr/devices.html http://www.freebsd.org/~eivind/newrc.html and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Johan, I quite agree that in the simple but better approach of rc.conf (BSD). However I like the idea of a configurable, directory driven approach to the shutdown. I would be apposed to sysV style rc.d's as I really don't think they provide anything but confusion. At the ISP where I work the BSD model is far easier to maintain. Personally far easier than the solaris, hp-ux, and linux machines we've had in the past Johan Granlund wrote: Please Please Please _Dont_!!! I dont know if someone is yoking, my english is not up to that :( I tried to secure a Solaris machine and hated the whole setup. I't have some good things but i take the simple rc.conf mechanism every time! /Johan On Mon, 10 Jul 2000, Mikel wrote: Kelly Yancey wrote: On Sat, 8 Jul 2000, Mike Meyer wrote: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... I like it. It's clean and simple, almost to the point of being elegant. But why bother adding rc?.d if you are going to right it to handle s or k then the present home should be fine, no? Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Network Operations Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard
Re: etc/rc.d things...
Andrzej Bialecki wrote: and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. I really like the ideas in the last one. The pages were not updated for some time - do you know if the author still works on it? No clue. At the time he decided to have a take on it, I traded many messages with him about it. I know he had part of it working, and could boot with it. After that, though, I never heard from him again. Like you, I really like his proposal. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On Tue, 11 Jul 2000, Daniel C. Sobral wrote: Andrzej Bialecki wrote: and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. I really like the ideas in the last one. The pages were not updated for some time - do you know if the author still works on it? No clue. At the time he decided to have a take on it, I traded many messages with him about it. I know he had part of it working, and could boot with it. After that, though, I never heard from him again. Like you, I really like his proposal. Hmm... Soon I will have some free time (holidays and stuff..). I'll take a look at it. It looks too good to be wasted. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
"Daniel C. Sobral" [EMAIL PROTECTED] writes: Mike Meyer wrote: Yes, that's correct. And yes, not all is bad in SysV. In particular, having a directory where you can find scripts to stop (and restart) subsystems is very nice. I think the multiple levels (rc?.d) is a bit of overkill. Either the system is up (meaning everything is turned on), or it's down, and the sysadmin who brought it down can start the subsystems s/he needs. Having a single init.d to look in for those things helps in that process. The multiple levels are there to deal with changes in state. In BSD, for instance, we have single user/multi-user. A number of other variations can exist, both in heavy duty servers where you might want to bring certain services down for upgrade and then back up, and "desktop" machines, such as notebooks where you can be stand-alone, docked into different networks (eg. home/work). Thing is, SysV does it in a very ugly way, and not flexible enough either. This has been talked to death. Look at these: http://www.freebsd.org/~dfr/devices.html off topic. http://www.freebsd.org/~eivind/newrc.html well. what about a mix of the SystemV approach (ala HP-UX) and the IRIX one (using something like chconfig). HP-UX : /sbin/init.d/script start_msg|stop_msg|start|stop (FMPOV, there isn't not enough possible choises, such as status, restart, config, command, etc.) /sbin/rc[S0-5].d/[SK][0-9][0-9][0-9]script linked to /sbin/init.d/script /sbin/rc (+ /sbin/rc.util) sources /etc/rc.config then runs /sbin/rc?.d startup files /etc/rc.config.d/services are configuration files (ala bourne shell). /sbin/rc.config sources /etc/rc.config.d configuration files. /usr/sbin/ch_rc is not so easy to use to modify /etc/rc.config.d/services. IRIX : oops, don't remember how works startup scripts. I just remember me configurations files : /sbin/chconfig [on|off] service or something like that. (don't remember if it's possible to change options through chconfig, but I guess no). /etc/config/services enable or disable services. /etc/config/services.options just contains arguments to services. so, a mix of both w/o the levels stuffs + a /etc/rc.default.d (a synonym to /etc/defaults/rc.conf but in separate files between HP-UX and IRIX configuration files) would be a begining. please, don't do something like AIX :) they use a binary database to stock there things... and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. effectively, the last one is interresting. a major problem w/ this one is the use of "perl" which is not available a boot time since it is located in /usr. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On 10 Jul 2000, Cyrille Lefevre wrote: and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. effectively, the last one is interresting. a major problem w/ this one is the use of "perl" which is not available a boot time since it is located in /usr. If we find out that it's very interesting, it should be implemented as part of init(8). (hint: init is NOT Perl based ;-) Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Andrzej Bialecki [EMAIL PROTECTED] writes: On 10 Jul 2000, Cyrille Lefevre wrote: and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. effectively, the last one is interresting. a major problem w/ this one is the use of "perl" which is not available a boot time since it is located in /usr. If we find out that it's very interesting, it should be implemented as part of init(8). (hint: init is NOT Perl based ;-) sould be a too big job for init ? mush better to be an external program a la /etc/rc, no ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Daniel C. Sobral writes: Mike Meyer wrote: The multiple levels are there to deal with changes in state. In BSD, for instance, we have single user/multi-user. A number of other variations can exist, both in heavy duty servers where you might want to bring certain services down for upgrade and then back up, and "desktop" machines, such as notebooks where you can be stand-alone, docked into different networks (eg. home/work). I'm familiar with why mutliple levels exist. I've never run into a system that had a real use for more than three run levels - powered off, maintenance, and up - though I've not dealt with notebooks. Needing to shut down some services in the up mode, or start some in the maintenance mode, is why having "start" and "stop" arguments to the scripts in rc.d is nice. If you find yourself needing to change to the state on a fixed bag of servers regularly, that feature on the scripts allows any admin worth hiring to write scripts to go back and forth easier than they can configure the SysV run levels. This doesn't work very well for the notebook example, though. Thing is, SysV does it in a very ugly way, and not flexible enough either. The functionality SysV provides isn't nearly worth the complexity. That was why I decided not to bother with it. Supporting multiple run levels adds lots of complexity. Tools to change run levels, hooks into init, etc. Possibly a simpler system - "run states" - which aren't layered like the SysV run levels would provide most of the functionality without anywhere near the complexity. The state transitions are all from single-user (where rc.shutdown takes you) to and from different up states, using different pairs of directories to rc the system. In this case, the K* and S* filenames make more sense, so there's only one directory per state. This would handle the notebook, and anything that required some set of services to be turned on from single-user mode for maintenance. and my favorite substitute proposal: http://www.roguetrader.com/~brandon/sas/. Having working code makes it a lot more attractive than any of the others - or what we've discussed here. It's also a lot more complex that what we've been discussing. If you're willing to work on getting this integrated into the core, cool. If not - then I'd still like to see something that is easier to configure and deals with startup/shutdown issues better. Thanx, mike P.S. - anyone else remember rc.single? Anyone care? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Mike Meyer [EMAIL PROTECTED] writes: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. Note that the directories full of symlinks are in /etc, not in /usr/X11R6/etc, etc. The rc.d's in those are also treated as repositories, so you can symlink to files in those asd well. These should save a bit of time at boot; no need to fool with lists of directories, etc. - just one directory. The real work will be adding a one-line description near the start of the file: # Init: 300. Shutdown: -1. Description: Standard smtp (mail) daemon. (indicating that it should be installed as /etc/init.d/300sendmail.sh, and no shutdown installation is necessary). I guess you would like to says that scripts.sh lives in /etc/init.d while XXXscripts.sh lives in /etc/rc.d and /etc/shutdown.d. if not, you are at the oposite of the SystemV semantic ! and would be a pain for system administrators. why not to simply adopt the SystemV semantic ? not all is bad in System V :) Later, we can add a tool that globs the etc/rc.d directories for files with those lines, and provides a nice visual "system process configuration" tool, allowing you to click on these things to move them back and forth. Some rules regarding the shutdown/startup priorites might be needed for ports. Given some prodding, I might even be talked into taking a crack at the tool (an X tool, maybe) before there's a commitment to supporting this structure. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
etc/rc.d things...
By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. Note that the directories full of symlinks are in /etc, not in /usr/X11R6/etc, etc. The rc.d's in those are also treated as repositories, so you can symlink to files in those asd well. These should save a bit of time at boot; no need to fool with lists of directories, etc. - just one directory. The real work will be adding a one-line description near the start of the file: # Init: 300. Shutdown: -1. Description: Standard smtp (mail) daemon. (indicating that it should be installed as /etc/init.d/300sendmail.sh, and no shutdown installation is necessary). Later, we can add a tool that globs the etc/rc.d directories for files with those lines, and provides a nice visual "system process configuration" tool, allowing you to click on these things to move them back and forth. Some rules regarding the shutdown/startup priorites might be needed for ports. Given some prodding, I might even be talked into taking a crack at the tool (an X tool, maybe) before there's a commitment to supporting this structure. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On Sat, 8 Jul 2000, Mike Meyer wrote: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
