Yes, there was an optimization added that will prevent a lookup if remap contains "127.0.0.1" or "::1" as these would previously end up hitting hostdb unnecessarily. Do you have entires in remap that map to a loopback interface via 127.0.0.1 or ::1?
Brian On Wed, Sep 9, 2015 at 12:27 PM, Esmq <[email protected]> wrote: > build pass on Debian 7 64bit, > > but ts behaved strangely with old config that previous work for v5.3.1 > (reverse proxy): > > ats return HTTP/1.1 404 Not Found on Accelerator for all request ~ > > remap.config: > regex_map http://(.*).aa.com/ http://$ > 1.aa.com/ > > diag.log: > [Sep 9 11:49:16.506] Server {0x2b6567a0e700} NOTE: cache enabled > [Sep 9 11:49:17.890] Server {0x2b6568014700} WARNING: pcre_exec() failed > with error code 0 > [Sep 9 11:49:17.892] Server {0x2b6566687e00} NOTE: traffic server running > [Sep 9 11:53:32.954] Server {0x2b6568115700} WARNING: pcre_exec() failed > with error code 0 > [Sep 9 11:53:38.587] Server {0x2b6566687e00} WARNING: pcre_exec() failed > with error code 0 > [Sep 9 11:59:57.908] Server {0x2b6567c10700} WARNING: pcre_exec() failed > with error code 0 > [Sep 9 12:04:42.012] Server {0x2b656770b700} WARNING: pcre_exec() failed > with error code 0 > [Sep 9 12:05:30.299] Server {0x2b6567e12700} WARNING: pcre_exec() failed > with error code 0 > > traffic.out(debug) > [Sep 9 12:23:43.091] Server {0x2b6567d11700} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > [Sep 9 12:23:53.094] Server {0x2b6567e12700} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > [Sep 9 12:24:03.098] Server {0x2b6567f13700} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > [Sep 9 12:24:13.102] Server {0x2b6568014700} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > [Sep 9 12:24:23.105] Server {0x2b6568115700} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > [Sep 9 12:24:33.109] Server {0x2b6566687e00} DEBUG: (dns) > [HttpTransact::HandleRequest] Skipping DNS lookup for 127.0.0.1 because > it's loopback > > > my pcre version: > ii libpcre3:amd64 1:8.30-5 > amd64 Perl 5 Compatible Regular Expression Library - runtime files > ii libpcre3-dev 1:8.30-5 > amd64 Perl 5 Compatible Regular Expression Library - development > files > ii libpcrecpp0:amd64 1:8.30-5 > amd64 Perl 5 Compatible Regular Expression Library - C++ runtime > files > > > At 2015-09-09 11:11:50, "Bryan Call" <[email protected]> wrote: > >I rsync it again and verified it worked. > > > >-Bryan > > > > > >> On Sep 8, 2015, at 7:59 PM, Leif Hedstrom <[email protected]> wrote: > >> > >> > >>> On Sep 8, 2015, at 8:44 PM, Gmail <[email protected]> wrote: > >>> > >>> HI!all > >>> > >>> uncompress 6.0.0-rc0.tar.bz2 fail! > >>> > >>> trafficserver-6.0.0/lib/wccp/Wccp.h > >>> trafficserver-6.0.0/lib/wccp/WccpMeta.h > >>> trafficserver-6.0.0/lib/wccp/WccpLocal.h > >>> trafficserver-6.0.0/lib/wccp/WccpMsg.cc bzip2: Compressed file ends > >>> unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: > >>> Inappropriate ioctl for device Input file = (stdin), output file = > >>> (stdout) It is possible that the compressed file(s) have become > >>> corrupted. You can use the -tvv option to test integrity of such files. > >>> You can use the `bzip2recover' program to attempt to recover data from > >>> undamaged sections of corrupted files. tar: Unexpected EOF in archive > >>> tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now > >> > >> > >> Confirmed, it’s broken. What’s odd is that this file got changed after the > >> checksum files were generated: > >> > >> - > >> > >> trafficserver-6.0.0-rc0.tar.bz2 > >> 08-Sep-2015 19:32 5.2M > >> > >> trafficserver-6.0.0-rc0.tar.bz2.asc > >> 08-Sep-2015 17:46 819 > >> > >> trafficserver-6.0.0-rc0.tar.bz2.md5 > >> 08-Sep-2015 17:45 66 > >> > >> trafficserver-6.0.0-rc0.tar.bz2.sha1 08-Sep-2015 17:45 74 > >> > >> > >> > >> — Leif > >> > > > > > > >
