Re: automatically restart httpd
Jim Albert <[email protected]>
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Organization | Netrition - The Internet's Premier Nutrition Superstore! |
| Message-ID | <[email protected]> |
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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 4/23/2013 1:36 PM, Ryan Perry wrote: >> >> >> >> >> On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> 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