I'm sick of people cp /etc/defaults/rc.conf /etc/rc.conf and complaining about being out of file descriptors during boot. This will let people do that silly thing, and it will stop them from trashing their box. Fix: Here's a patch against v1.53 of rc.conf . It might be a good idea to insert an echo or two to give the user a big warning. How-To-Repeat: cp /etc/defaults/rc.conf /etc/rc.conf reboot
Nice! Could someone please commit that?-) Alex
adrian@creative.net.au wrote: > --- /usr/src/etc/defaults/rc.conf Thu Mar 16 10:15:20 2000 > +++ rc.conf Sat Mar 25 10:33:06 2000 > @@ -291,9 +291,13 @@ > # > # > > -for i in ${rc_conf_files}; do > - if [ -f $i ]; then > - . $i > - fi > -done > +# Anti-loop detection > +if [ "x$self_rcconf" != "xyes" ]; then > + self_rcconf="yes" > + for i in ${rc_conf_files}; do > + if [ -f $i ]; then > + . $i > + fi > + done > +fi Here's the problem with this approach. More than one script in /etc/rc* sources the rc.conf files in the process of booting. Using this approach those scripts (like rc.firewall, rc.network*, etc.) only source /etc/defaults/rc.conf when they are started, and never source the user's customizations. I have been giving this a lot of thought, and I think the correct approach would be to put a function that knows how to source the various combos of rc.conf* files (similar to the current code, or maybe exactly like it, I haven't tested it yet) at the end of /etc/defaults/rc.conf and then make each script that sources the conf files responsible for running the recursive source itself. This is a slightly less elegant solution, but it will solve this problem once and for all. I'll try to work up some patches tomorrow... Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu."
State Changed From-To: open->feedback Under discussion
Responsible Changed From-To: freebsd-bugs->dan I'll look after this...
On Sat, Mar 25, 2000, Doug Barton wrote: > Here's the problem with this approach. More than one script in /etc/rc* > sources the rc.conf files in the process of booting. Using this approach > those scripts (like rc.firewall, rc.network*, etc.) only source > /etc/defaults/rc.conf when they are started, and never source the user's > customizations. > > I have been giving this a lot of thought, and I think the correct > approach would be to put a function that knows how to source the various > combos of rc.conf* files (similar to the current code, or maybe exactly > like it, I haven't tested it yet) at the end of /etc/defaults/rc.conf > and then make each script that sources the conf files responsible for > running the recursive source itself. This is a slightly less elegant > solution, but it will solve this problem once and for all. > > I'll try to work up some patches tomorrow... > Nope, unless I missed something completely, /etc/defaults/rc.conf will be run, it'll call /etc/rc.conf, rc.conf will include the local customisations, but because self_rcconf is set to 'yes' this time, it won't go and reexecute the rc conf scripts. Unless I missed something stupidly big of course, now that I'm back in front of my own -current machine I'm going to give it another run. I'm not paying attention to mailing lists atm, so please CC: me on any further discussions here. Adrian
Adrian Chadd wrote: > > On Sat, Mar 25, 2000, Doug Barton wrote: > > > Here's the problem with this approach. More than one script in /etc/rc* > > sources the rc.conf files in the process of booting. Using this approach > > those scripts (like rc.firewall, rc.network*, etc.) only source > > /etc/defaults/rc.conf when they are started, and never source the user's > > customizations. > > > > I have been giving this a lot of thought, and I think the correct > > approach would be to put a function that knows how to source the various > > combos of rc.conf* files (similar to the current code, or maybe exactly > > like it, I haven't tested it yet) at the end of /etc/defaults/rc.conf > > and then make each script that sources the conf files responsible for > > running the recursive source itself. This is a slightly less elegant > > solution, but it will solve this problem once and for all. > > > > I'll try to work up some patches tomorrow... > > > > Nope, unless I missed something completely, /etc/defaults/rc.conf > will be run, it'll call /etc/rc.conf, rc.conf will include the local > customisations, but because self_rcconf is set to 'yes' this time, it > won't go and reexecute the rc conf scripts. Please re-read what I wrote. The problem comes with scripts like rc.firewall and rc.network which also source the rc.conf's during boot. Using your approach (which several of us tried a while back already) these scripts source /etc/defaults/rc.conf, then don't go on to source the user's custom files. As you can imagine this causes all manner of problems. I'm currently working on implementing the idea I outlined above, I should have some patches to test in the next couple of hours (depending on how exciting the oscars are :). Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu."
State Changed From-To: feedback->analyzed A solution discussed on this PR has been committed to HEAD. I'd like to hold off on MFC for a month. If, in that time, Neil Blakey-Milner comes up with a way of breaking the new source_rc_confs function out into its own shell script without negatively affecting its usefulness, the wait will have been prudent.
Responsible Changed From-To: dan->sheldonh This is my MFC reminder: src/etc/netstart 1.55 src/etc/pccard_ether 1.16 src/etc/rc 1.215 src/etc/rc.devfs 1.8 src/etc/rc.diskless2 1.6 src/etc/rc.firewall 1.33 src/etc/defaults/rc.conf 1.59 If Neil decides to go ahead with breaking this out into its own file, he's welcome to take over responsibility for this PR.
State Changed From-To: analyzed->closed I MFC'd this a while ago before sheldonh had a chance to do it himself. No need for the PR to stick around IMHO. Reminded of PR by: nbm