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

From: Garrett Cooper <yaneurabeya_at_gmail.com>
Date: Tue, 11 Aug 2015 11:01:16 -0700
> 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..
Received on Tue Aug 11 2015 - 16:01:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC