On 4/23/2013 3:09 PM, Jim Albert wrote:
On 4/23/2013 2:33 PM, Ryan Perry wrote:



On Tue, Apr 23, 2013 at 12:47 PM, Jim Albert <j...@netrition.com
<mailto:j...@netrition.com>> wrote:

    On 4/23/2013 1:36 PM, Ryan Perry wrote:




        On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert <j...@netrition.com
        <mailto:j...@netrition.com>
        <mailto:j...@netrition.com <mailto:j...@netrition.com>>> wrote:

             On 4/23/2013 1:08 PM, Ryan Perry wrote:

                 I've considered doing it daily via cron, but if there's
        a way to
                 do when
                 I hit this error I'd prefer that.


                 On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert
        <j...@netrition.com <mailto:j...@netrition.com>
                 <mailto:j...@netrition.com <mailto:j...@netrition.com>>
                 <mailto:j...@netrition.com <mailto:j...@netrition.com>
        <mailto:j...@netrition.com <mailto:j...@netrition.com>>>> wrote:

                      On 4/23/2013 11:49 AM, Ryan Perry wrote:

                          I've been plagued by some bug that makes a
        call to LWP
                 stop working:
                          "Can't connect to 192.168.0.222 (Bad hostname)"

                          I haven't been able to figure out why, but a
        simple httpd
                          restart fixes
                          it for a day or 2.

                          Since I can't figure out a real fix, I'm
        wondering if
                 there is a
                          way for
                          me to automatically restart httpd whenever
the bug
                 hits.  Maybe
                          whenever
                          it appears in the httpd-error.log?  What are
        my options?


                      Without more to go on to the actual cause of the
        problem...

                      Restarting apache daily isn't a bad idea in
        general if even
                 just a
                      graceful restart.
                      kill -USR1 `cat /var/run/httpd.pid`
                      which I believe should be safe any time of day.

                      If a complete restart, maybe early morning off
hours
                 assuming your
                      server requires a high degree of availability?

                      Jim


             Try to remember not to top-post, please. It makes it hard
        for others
             to read the thread.

             I don't know, but it kind of has a DNS feel to it,
        possibly. Nothing
             concrete to go on, just past experience when I see network
        and I
             know the network is fine... I think DNS. Maybe reverse
        resolution of
             your private IP address space assuming your requests are
        being made
             to/from private addresses? That's really just a shot in the
        dark
             because we don't have much to go on. I'd start thinking
        network and
             DNS, put in some debug, see what if anything is timing out.

             Jim


        Sorry about the top post.

        I've done the debugging on DNS.  If it try changing the
        IP/hostname I
        still get the error.  I think it's per-process though.  Once it
        starts
        to happen it's intermittent and gets worse, making me think
        depending
        which process I hit it will work or not until all processes are
        affected.

        This is on FreeBSD using a jailed (virtualized) host.  I read
about
        apache/jails on OpenBSD having a config issue with DNS but it
seemed
        different than this.

        It only seems to affect httpd, I can log in and ping from the
server
        just fine.


    Also, please reply to the list, not personal email addresses so
    everyone else gets the benefit of the thread, and maybe you get a
    better answer from someone other than me. :)

    I'm not so sure you've eliminated DNS, yet.

    What if from 192.168.0.222 you:
    dig -x 192.168.0.x

    where 192.168.0.x is the IP addressing making the connection to
    192.168.0.222

    Do you have reverse resolvers for your private address space or are
    the requests handled by the top level root servers?

    Who is answering for that reverse resolution request?
    dig -x 192.168.0.x
    Is it your resolver or a root level like prisoner.iana.org
    <http://prisoner.iana.org>

    Jim


Interesting, but it seems hard to believe that would be it.  I don't
have any other suspects though...


; <<>> DiG 9.8.3-P3 <<>> -x 192.168.0.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20209
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;200.0.168.192.in-addr.arpa.INPTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.10800INSOAlocalhost. nobody.invalid. 1 3600 1200
604800 10800

;; Query time: 6 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Tue Apr 23 18:28:37 2013
;; MSG SIZE  rcvd: 103
You're using a public resolver... 4.2.2.1
I'm not saying that's your problem, but I've had problems in the past
where connections were slow or timed out doing a reverse lookup of my
private address space. The problem went away after configuring my own
resolvers to handle reverse lookups on my private address space.

If you want to continue to use 4.2.2.1 or any public resolver as your
resolver, that's not an option.

If you have your own resolvers, this might help:
http://www.sendmail.com/sm/open_source/tips/private_dns/

Again... I'm still kind of shooting in the dark, so my confidence level
on where I'm going with this is not high.

You really should put some debug in or maybe a packet trace... is your
server actually getting the request is where I would start.

Does your ISP provide a resolver? Is there a reason you want to use
4.2.2.1 rather than your ISP's or your own or maybe at least Google's at
8.8.8.8?

Jim


As a test, you could configure 192.168.0.200 in 192.168.0.222's /etc/hosts
Offhand, you could just make up a name for it.
192.168.0.200   just_testing

That might help confirm if reverse resolution is the issue as in normal configuration /etc/hosts is the first level of resolution prior to DNS being queried.

Jim

Reply via email to