Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
in the "hosts" array and eventually looks up the network address with
getaddrinfo(). At one point it checks for a numeric address and if it
sees one, it sets a hint parameter to force getaddrinfo to interpret the
host as a numeric address. However that hint is not cleared for subsequent
iterations of the loop and if any hosts seen after this point are host names,
getaddrinfo will fail on the name. The result of this bug is that you cannot
pass a host name to the -h flag.
Unfortunately, the first iteration will either process ::1 or 127.0.0.1,
so the flag is set on the first iteration and all host names will fail
to be processed.
The same bug applies to rpc.lockd and rpc.statd, so fix them too.
Differential Revision: https://reviews.freebsd.org/D1507
Reported by: Dylan Martin
MFC after: 1 week
Sponsored by: Sandvine Inc.
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
provides the correct semantics for flock(2) style locks which are used by the
lockf(1) command line tool and the pidfile(3) library. It also implements
recovery from server restarts and ensures that dirty cache blocks are written
to the server before obtaining locks (allowing multiple clients to use file
locking to safely share data).
Sponsored by: Isilon Systems
PR: 94256
MFC after: 2 weeks
and in mountd(8)
-h bindip
Specify specific IP addresses to bind to for TCP and UDP requests.
This option may be specified multiple times. If no -h option is
specified, rpc.statd will bind to INADDR_ANY. Note that when specifying
IP addresses with -h, rpc.statd will automatically add 127.0.0.1 and if
IPv6 is enabled, ::1 to the list.
(coming for rpc.lockd too)
PR: bin/98500
MFC after: 1 week
message and then dumps core because the subsequent code assumes that
mmap() succeeded. Since rpc.statd does not have fallback code to
implement the functionality needed to operate on the status file if
it is not memory mapped, rpc.statd should use err() to force the process
to exit if the mmap() call fails.
PR: bin/115430 (mmap() failure previously fixed in statd.c 1.15)
Approved by: re (kensmith)
MFC after: 1 week
otherwise mmap() gets called multiple times, which eventually fails due
to address space exhaustion on i386.
Approved by: re (kensmith)
MFC after: 1 week
to sockaddr ones and using svc_getrpccaller instead of svc_getcaller.
A similar patch was committed to rpc.lockd back in 2002 .
PR: bin/42004
MFC after: 1 week
request, correctly report the location (usually localhost) to which
a callback will be made when a notification is received for the
monitored host. Previsouly, the name of the monitored host was
reported instead.
MFC after: 2 weeks
most of the time (unless fork fails). This should fix the problem where
FreeBSD won't respond to a remote host and therefor the remote hosts
tries indefinitely to contact the FreeBSD hosts thereby irritating the
system administrator.
PR: misc/27810
