On 4/23/2013 2:33 PM, Ryan Perry wrote:
You're using a public resolver... 22.214.171.124
On Tue, Apr 23, 2013 at 12:47 PM, Jim Albert <email@example.com<mailto:firstname.lastname@example.org>> wrote:
On 4/23/2013 1:36 PM, Ryan Perry wrote:
On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert <email@example.com
<mailto:firstname.lastname@example.org><http://prisoner.iana.org><mailto:email@example.com <mailto:firstname.lastname@example.org>>> 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
I hit this error I'd prefer that.
On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert
<mailto:email@example.com <mailto:firstname.lastname@example.org>>>> wrote:
On 4/23/2013 11:49 AM, Ryan Perry wrote:
I've been plagued by some bug that makes a
call to LWP
"Can't connect to 192.168.0.222 (Bad hostname)"
I haven't been able to figure out why, but a
it for a day or 2.
Since I can't figure out a real fix, I'm
there is a
me to automatically restart httpd whenever the bug
it appears in the httpd-error.log? What are
Without more to go on to the actual cause of the
Restarting apache daily isn't a bad idea in
general if even
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
server requires a high degree of availability?
Try to remember not to top-post, please. It makes it hard
to read the thread.
I don't know, but it kind of has a DNS feel to it,
concrete to go on, just past experience when I see network
know the network is fine... I think DNS. Maybe reverse
your private IP address space assuming your requests are
to/from private addresses? That's really just a shot in the
because we don't have much to go on. I'd start thinking
DNS, put in some debug, see what if anything is timing out.
Sorry about the top post.
I've done the debugging on DNS. If it try changing the
still get the error. I think it's per-process though. Once it
to happen it's intermittent and gets worse, making me think
which process I hit it will work or not until all processes are
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
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
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.org168.192.in-addr.arpa.10800INSOAlocalhost. nobody.invalid. 1 3600 1200
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:
;; AUTHORITY SECTION:
;; Query time: 6 msec
;; SERVER: 126.96.36.199#53(188.8.131.52)
;; WHEN: Tue Apr 23 18:28:37 2013
;; MSG SIZE rcvd: 103
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 184.108.40.206 or any public resolver as your resolver, that's not an option.
If you have your own resolvers, this might help:
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 220.127.116.11 rather than your ISP's or your own or maybe at least Google's at 18.104.22.168?