fail with "bind: address already in use". This problem was reported
to the freebsd-stable@ mailing list on Feb. 19 under the subject
heading "statd/lockd startup failure" by george+freebsd at m5p dot com.
The problem is that the first combination of {udp,tcp X ipv4,ipv6}
would select a port# dynamically, but one of the other three combinations
would have that port# already in use. The patch is somewhat involved
because it was requested by dougb@ that the four combinations use the
same port# wherever possible. The patch splits the create_service()
function into two functions. The first goes as far as bind(2) in a
loop for up to GETPORT_MAXTRY - 1 times, attempting to use the same port#
for all four cases. If these attempts fail, the last attempt allows
the 4 cases to use different port #s. After this function has succeeded,
the second function, called complete_service(), does the rest of what
create_service() did.
The three daemons mountd, rpc.lockd and rpc.statd all have a
create_service() function that is patched in a similar way. However,
create_service() has non-trivial differences for the three daemons
that made it impractical to share the same functions between them.
Reviewed by: jhb
MFC after: 2 weeks
fail with "bind: address already in use". This problem was reported
to the freebsd-stable@ mailing list on Feb. 19 under the subject
heading "statd/lockd startup failure" by george+freebsd at m5p dot com.
The problem is that the first combination of {udp,tcp X ipv4,ipv6}
would select a port# dynamically, but one of the other three combinations
would have that port# already in use. The patch is somewhat involved
because it was requested by dougb@ that the four combinations use the
same port# wherever possible. The patch splits the create_service()
function into two functions. The first goes as far as bind(2) in a
loop for up to GETPORT_MAXTRY - 1 times, attempting to use the same port#
for all four cases. If these attempts fail, the last attempt allows
the 4 cases to use different port #s. After this function has succeeded,
the second function, called complete_service(), does the rest of what
create_service() did.
The three daemons mountd, rpc.lockd and rpc.statd all have a
create_service() function that is patched in a similar way. However,
create_service() has non-trivial differences for the three daemons
that made it impractical to share the same functions between them.
Reviewed by: jhb
MFC after: 2 weeks
fail with "bind: address already in use". This problem was reported
to the freebsd-stable@ mailing list on Feb. 19 under the subject
heading "statd/lockd startup failure" by george+freebsd at m5p dot com.
The problem is that the first combination of {udp,tcp X ipv4,ipv6}
would select a port# dynamically, but one of the other three combinations
would have that port# already in use. The patch is somewhat involved
because it was requested by dougb@ that the four combinations use the
same port# wherever possible. The patch splits the create_service()
function into two functions. The first goes as far as bind(2) in a
loop for up to GETPORT_MAXTRY - 1 times, attempting to use the same port#
for all four cases. If these attempts fail, the last attempt allows
the 4 cases to use different port #s. After this function has succeeded,
the second function, called complete_service(), does the rest of what
create_service() did.
The three daemons mountd, rpc.lockd and rpc.statd all have a
create_service() function that is patched in a similar way. However,
create_service() has non-trivial differences for the three daemons
that made it impractical to share the same functions between them.
Reviewed by: jhb
MFC after: 2 weeks
to the final name if netconfig was completely finished. This fixes
reentrance problems even better than r222611.
Suggested by: nwhitehorn
Reviewed by: nwhitehorn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
interface. Otherwise an accidental start of the netowrk configuration
and immediate cancel after the install has finished removes the previously
configured settings.
Discussed with: nwhitehorn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
These cause problems when trying to include the header in a C++ project.
Rename them to 'evt_class', and track the change in mfi and mfiutil.
Submitted by: Mark Johnston
Sponsored by: Sandvine Incorporated
Reviewed by: jhb@
MFC after: 1 week
Add some additional empty string checks for IPv4 and try to configure
a netmask along with the address rather than doing things twice.
Contrary to AUTO-DHCP, IPv6-SLAAC will accept static configuration
as well, which we will use at least for resolv.conf currently and
if we were given a static address configure that as an alias as well.
The pc-sysinstaller changes going along were committed to PC-BSD as r10773.
Reviewed by: kmoore
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 20 days
- netconfig - what auto will call which in turn will check for
IPv4 and IPv6 to be available and ask the user to configure it
by calling
- netconfig_ipv4 doing DHCP and static IPv4 addresses, and
- netconfig_ipv6 doing rtsol and static IPv6 addresses,
and then checking, querying and updating resolv.conf upon return.
Both DHCP and rtsol (in the future) might update resolv.conf already so
we seed ourselves from that file if available.
Reviewed by: nwhitehorn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
provoke errors trying to query options not available.
Make it possible to compile out INET or INET6 only parts.
Reviewed by: jamie
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 10 days
will be considered as a path to a binary or a shell script to be executed
after rotation has been completed instead of sending signal to the process
id in that file.
Sponsored by: Sippy Software, Inc.
From the: FreeBSD hacking lounge at BSDCan
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
configuration files.
If the current file differs from the canonical version from the old release
only due to differences in the $FreeBSD$ tag (which can happen if the system
was installed from source code, depending on how the src tree was checked out)
then freebsd-update will treat the file as "unmodified" and silently update
it to the "clean" version in the new release.
If the only change being made to a configuration file is in the $FreeBSD$
tag (e.g., for any configuration files which have been modified locally, now
that we're using SVN and the $FreeBSD$ tag changes when a branch is created),
freebsd-update will no longer print the diff and prompt "Does this look
reasonable (y/n)?".
Nagged by: pgollucci
MFC after: 1 month
