was overlapping with another file, and making some undesirable behavior a
little worse - it's triggering a bug in config that appears to have been
there for some time (before the options files, anyway.)
This will make FreeBSD boxes better behaved 'MBONE Citizens', based on
a couple of the comments about the severity of fixes..
Agreed to by: wollman, fenner@parc.xerox.com
conflict markers, but it actually changes nothing.
We've been running this code with small changes for some time, this may
be useful for checking what those changes. It was unfortunate this
module got so far away from the vendor branch (whitespace changes didn't
help)
- Fix a SEGV condition in ypxfr_main.c that reared its ugly head while I
was working on the 'parallel jobs' feature of the new yppush. After we've
completed the map transfer and created a local temporary copy, we check
the order number of the map on ypserv again to make sure it didn't change
while the transfer was in progress (map skew). If for some reason we flat
out fail to get the order number from the server, we flag this as an
error and bail, telling ypxfr_exit() to clean up our temporary files
for us. However, ypxfr_exit() tries to close the database before unkining
it, not realizing that it has already been closed prior to the skew check.
The second attempt to close the database causes a SEGV somewhere inside
the DB code.
(Well, it does on my 2.0.5 machine anyway. I haven't seen anyone modify
the DB library code in ages, so the condition is probably still there.)
To work around this, we deliberately set dbp to NULL after closing the
database and check for the condition in ypxfr_exit(), being careful to
avoid the second close if we see the NULL.
- In yp_dbwrite.c, make yp_open_db_rw() open the database with O_EXLOCK
flag set. This probably won't affect much of anything, but I feel better
having it there.
On some laptops, this doesn't work (ie; IBM 75x series), so force it
to power on.
With this modification, I am able to read the tuples off 4 different
PCMCIA cards on my ThinkPad.
Reviewed by: phk@FreeBSD.org
Obtained from: if_zp.c
the range [210:260] by sweeping the problem under the rug. This change
has the following effects:
1) A new MIB variable in the kern branch is defined to allow modification
of the socket buffer layer's ``wastage factor'' (which determines how
much unused-but-allocated space in mbufs and mbuf clusters is allowed
in a socket buffer).
2) The default value of the wastage factor is changed from 2 to 8.
The original value was chosen when MINCLSIZE was 7*MLEN (!), and is not
appropriate for an environment where MINCLSIZE is much less.
The real solution to this problem is to scrap both mbufs and sockbufs
and completely redesign the buffering mechanism used at both levels.
to enable IP forwarding, use sysctl(8). Also did the same for IPX,
which involved inventing a completely new MIB from whole cloth (which
I may not quite have correct); be aware of this if you use IPX forwarding.
(The two should never have been controlled by the same option anyway.)
consider "safe" for most systems. Note that this is (has been for some
time) also tunable with sysctl (via kern.somaxconn) should the operator
wish to increase this value even higher. Also note that 128 is what
the Netscape WWW server reportedly asks for.
"hand", changed /etc/crontab to call /usr/sbin/newsyslog every hour
(the entry was there before - but we haven't had any newsyslog until
today :-) and changed /etc/inetd.conf to also contain (commentet out)
entries for rpc.rquotad and rpc.sprayd (taken from NetBSD)
imported the newsyslog command from NetBSD - it make the "rotation" of
the logfiles much simpler (it is currently done by "hand" in the
/etc/[daily,weekly,monthly] scripts) - now it will be done by invoking
newsyslog every hour which is very customizable via a
/etc/newsyslog.conf file
