Re: r286615: /usr/libexec/ftpd broken!

On Tue, 11 Aug 2015 11:01:16 -0700
Garrett Cooper <yaneurabeya_at_gmail.com> wrote:

> 
> > On Aug 11, 2015, at 06:01, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote:
> > 
> > On Tue, 11 Aug 2015 14:05:36 +0200
> > "O. Hartmann" <ohartman_at_zedat.fu-berlin.de> wrote:
> > 
> >> On Tue, 11 Aug 2015 13:18:14 +0200
> >> Ed Schouten <ed_at_nuxi.nl> wrote:
> >> 
> >>> Hi there,
> >>> 
> >>> 2015-08-11 10:44 GMT+02:00 O. Hartmann <ohartman_at_zedat.fu-berlin.de>:
> >>>> ftpd starts sometimes, sporadically, and dies somewhere in the process.
> >>>> Connections to the ftpd aren't possible. Sockstat doesn't even show up a
> >>>> TCP/IP socket (21, ftp/tcp) where the daemon is supposed to listen for
> >>>> incoming connection - I see only udp4 (connecting to
> >>>> local_unbound/127.0.0.1:53). This is strange ...
> >>> 
> >>> That's annoying. We should fix that.
> >>> 
> >>> I recently made some changes to shutdown(2), but a grep reveals that
> >>> ftpd doesn't call that function anywhere. Phew! The last changes made
> >>> to ftpd are related to libxo. Adding marcel_at_, just to be sure.
> >>> 
> >>> In the meantime, could you maybe run truss(8) over ftpd and send us the
> >>> output?
> >>> 
> >>> Thanks,
> >> 
> >> I found one of our boxes, running
> >> 
> >> FreeBSD 11.0-CURRENT #0 r286562: Mon Aug 10 08:14:52 CEST 2015 amd64
> >> 
> >> which runs ftpd without problems (started via service ftpd onestart):
> >> 
> >> USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN
> >> ADDRESS root     ftpd       23139 3  dgram  -> /var/run/logpriv
> >> root     ftpd       23139 5  tcp6   *:21                  *:*
> >> root     ftpd       23139 6  tcp4   *:21                  *:*
> >> 
> >> 
> >> ... as expected ... and the daemon is running for several minutes for
> >> now ...
> >> 
> >> I will update the system as well and then ... see ... ;-)
> > 
> > Well, after the update to FreeBSD 11.0-CURRENT #1 r286625: Tue Aug 11
> > 14:09:55 CEST 2015  amd64, ftpd is still working! This box is the only one
> > that does nameresolution via DNS (external), while all non-functional
> > systems do not have DNS resolution and work with local_unbound name
> > resolving.
> 
> Something is indeed weird with DNS under some circumstances as of a few weeks
> ago. I'm trying to update my box and I'm seeing a ton of complaints about
> unbound handing back A records instead of AAAA ones. My machine is on an IPv4
> NAT network, but I still find it odd how my last update a few weeks ago
> started causing this..


It seems to me as ftpd never binds to a TCP port