Re: varnishlog not behaving as expected (by me)
Hi, It's OK: I'm used to not receiving responses from mailing lists. I have an unfortunate way of communicating in such forums, I think. Anyway, having come back to this after a slight hiatus I have noted that the inclusion of the '-c' flag makes it work as expected. If I instead include the '-b' flag, it also seems to work as expected (ie, it doesn't spew output, returns data on backend requests where tag/regex matched). If I include both -b and -c, it continues to work -- but if I include neither, I get the type of spurious* output I noted originally, no matter what the combination of tag and regex. My reading of the man page is that varnishlog -o tag regex is semantically equivalent to varnishlog -b -c -o tag regex Either I or the code or the man page would appear to be wrong. Cheers, Alex. * The use of this term may be subjective. Alex Hooper uttered: Hi, I'm having a bit of trouble using varnishlog. I am using: /usr/local/bin/varnishlog -o RxURL ^wp-admin$ Expecting to see grouped log lines for requests where the RxURL matches /^wp-admin$. But the (copious) output I see is like: 0 StatAddr - 59.181.130.123 0 6 1 3 0 0 0 1003 8711 0 StatAddr - 120.28.216.236 0 1 6 11 0 0 0 3864 92763 0 StatAddr - 80.13.50.156 0 754 22 40 0 0 0 7080 0 0 StatAddr - 86.156.98.226 0 0 2 4 0 0 0 1397 9259 0 ExpPick - 1023444941 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444941 -1263381538 0 ExpPick - 1023444953 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444953 -1263381538 0 ExpPick - 1023108126 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023108126 -10 0 ExpPick - 1023109753 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug- Attempt Prefetch 1023109753 0 StatAddr - 86.156.98.226 0 0 3 5 0 0 0 1750 22988 0 StatAddr - 193.146.115.134 0 12 4 4 0 0 0 708 0 0 StatAddr - 86.156.98.226 0 0 4 6 0 0 0 2103 36115 0 StatAddr - 80.13.50.156 0 754 22 41 0 0 0 7257 0 0 StatAddr - 80.13.50.156 0 754 23 42 0 0 0 7434 0 '/usr/local/bin/varnishlog' -i RxURL shows me the requests coming in. '/usr/local/bin/varnishlog -i RxURL|grep wp-admin' shows that there are generally no requests for wp-admin. Am I missing something obvious? (varnish-2.0.4 on RHEL 5.4) Cheers, Alex. -- Alex Hooper | w www.bmjpg.com Operations Team Leader| e ahoo...@bmjgroup.com BMJ Technology, BMJ Publishing Group | t +44 20 7383 6049 BMA House, LONDON, WC1H 9JR | ___ The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK. ___ ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
varnishlog not behaving as expected (by me)
Hi, I'm having a bit of trouble using varnishlog. I am using: /usr/local/bin/varnishlog -o RxURL ^wp-admin$ Expecting to see grouped log lines for requests where the RxURL matches /^wp-admin$. But the (copious) output I see is like: 0 StatAddr - 59.181.130.123 0 6 1 3 0 0 0 1003 8711 0 StatAddr - 120.28.216.236 0 1 6 11 0 0 0 3864 92763 0 StatAddr - 80.13.50.156 0 754 22 40 0 0 0 7080 0 0 StatAddr - 86.156.98.226 0 0 2 4 0 0 0 1397 9259 0 ExpPick - 1023444941 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444941 -1263381538 0 ExpPick - 1023444953 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444953 -1263381538 0 ExpPick - 1023108126 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023108126 -10 0 ExpPick - 1023109753 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug- Attempt Prefetch 1023109753 0 StatAddr - 86.156.98.226 0 0 3 5 0 0 0 1750 22988 0 StatAddr - 193.146.115.134 0 12 4 4 0 0 0 708 0 0 StatAddr - 86.156.98.226 0 0 4 6 0 0 0 2103 36115 0 StatAddr - 80.13.50.156 0 754 22 41 0 0 0 7257 0 0 StatAddr - 80.13.50.156 0 754 23 42 0 0 0 7434 0 '/usr/local/bin/varnishlog' -i RxURL shows me the requests coming in. '/usr/local/bin/varnishlog -i RxURL|grep wp-admin' shows that there are generally no requests for wp-admin. Am I missing something obvious? (varnish-2.0.4 on RHEL 5.4) Cheers, Alex. -- Alex Hooper | w www.bmjpg.com Operations Team Leader| e ahoo...@bmjgroup.com BMJ Technology, BMJ Publishing Group | t +44 20 7383 6049 BMA House, LONDON, WC1H 9JR | ___ The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK. ___ ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)
Ken Brownfield uttered: Your tcpdump seems to imply that there's an immediate timeout on the connection. Do the timeouts (and other settings) emitted from varnishadm -T :6082 param.show all have sane values? As far as I can tell...: accept_fd_holdoff 50 [ms] acceptor default (ports, poll) auto_restart on [bool] backend_http11 on [bool] between_bytes_timeout 60.00 [s] cache_vbe_connsoff [bool] cc_command cc -Kpic -G -o %o %s cli_buffer 8192 [bytes] cli_timeout5 [seconds] client_http11 off [bool] clock_skew 10 [s] connect_timeout5.00 [s] default_grace 10 default_ttl120 [seconds] diag_bitmap0x0 [bitmap] err_ttl0 [seconds] esi_syntax 0 [bitmap] fetch_chunksize128 [kilobytes] first_byte_timeout 60.00 [s] group nobody (60001) listen_address :80 listen_depth 1024 [connections] log_hashstring off [bool] log_local_address off [bool] lru_interval 2 [seconds] max_esi_includes 5 [includes] max_restarts 4 [restarts] obj_workspace 8192 [bytes] overflow_max 100 [%] ping_interval 3 [seconds] pipe_timeout 60 [seconds] prefer_ipv6off [bool] purge_dups off [bool] purge_hash on [bool] rush_exponent 3 [requests per request] send_timeout 600 [seconds] sess_timeout 5 [seconds] sess_workspace 16384 [bytes] session_linger 0 [ms] shm_reclen 255 [bytes] shm_workspace 8192 [bytes] srcaddr_hash 1049 [buckets] srcaddr_ttl30 [seconds] thread_pool_add_delay 20 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_fail_delay 200 [milliseconds] thread_pool_max500 [threads] thread_pool_min5 [threads] thread_pool_purge_delay1000 [milliseconds] thread_pool_timeout300 [seconds] thread_pools 2 [pools] user nobody (60001) vcl_trace off [bool] I did note this in config.log; not sure if it implies the kind of problem I'm seeing: configure:19586: checking whether SO_SNDTIMEO works configure:19629: gcc -std=gnu99 -o conftest -g -O2 conftest.c 5 Undefined first referenced symbol in file socket /var/tmp//ccKa38Tg.o setsockopt /var/tmp//ccKa38Tg.o ld: fatal: Symbol referencing errors. No output written to conftest ... configure:19673: WARNING: connection timeouts will not work You might also experiment by adding a probe to your backend, to see if the probes pass. They show as sick, with the same reset symptom in tcpdump. Otherwise, I guess I'd suspect an issue with compilation. They say Varnish only supports gcc (which might not be strictly true, but I'll bet it's not tested under the Sun compiler). What was the isfinite() issue? The same as that reported at http://varnish.projects.linpro.no/ticket/464. Actually, having re-tried, I can get around the isfinite() issue with the provided patch, but am caught by the second issue with NAN. I get: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -DVARNISH_STATE_DIR='/local/var/varnish' -g -O2 -MT varnishd-cache_center.o -MD -MP -MF .deps/varnishd-cache_center.Tpo -c -o varnishd-cache_center.o `test -f 'cache_center.c' || echo './'`cache_center.c cache_center.c: In function `cnt_done': cache_center.c:234: error: incompatible types in assignment cache_center.c:241: error: incompatible types in assignment *** Error code 1 It's starting to look as though there may be a few too many issues with Varnish on Solaris currently. I'll keep trying to resolve, but time issues may force me to fall back to squid for the moment. Cheers, Alex. -- Alex Hooper | w www.bmjpg.com Systems and Database Administration | e ahoo...@bmjgroup.com BMJ Technology, BMJ Publishing Group | t +44 20 7383 6049 BMA House, LONDON, WC1H 9JR | ___ The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses
tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)
Hi,
Having a requirement to ease the load on a high-traffic site of ours, I
was recently diverted from reaching for Squid by a colleague who
recommended Varnish.
I grabbed the source for 2.0.4 (having looked for a package but not
found one, despite a suggestion that it was available as part of Sun's
Webstack) and compiled it using the compiler bundled with Sun Studio 12
update 1 (having initially tried using gcc and hitting a problem with
isfinite()).
All compiled fine so I created a simple test config:
backend test01 {
.host = 83.231.175.37;
.port = 80;
.connect_timeout = 10s;
.first_byte_timeout = 15s;
.between_bytes_timeout = 2s;
}
sub vcl_recv {
set req.backend = test01;
}
and started up with
varnishd -a :80 -T localhost:6082 -p sess_timeout=60 -f
/local/etc/varnish/bmjgroup.vcl
That looked OK, but requests to varnish all gave 503s. Watching the
logs, I could see that flow was passing from 'pass' to 'error', but was
given no more clue. It wasn't until I watched the packets on the wire
that I saw that Varnish was sending resets before even completing a
handshake:
varnish - web: SYN
varnish - web: RST
web - varnish: SYN ACK
varnish - web: RST
Having searched the wiki, mailing lists and bug database for a
resolution to this, I found nothing except for issue #522 (Odd TCP reset
problems with trunk 4080) which seems not to be related.
I compiled, and am running varnish on, Solaris 10 5/08 (SPARC).
I wonder does anyone have an idea of what might be happening?
Cheers,
Alex.
--
Alex Hooper | w www.bmjpg.com
Systems and Database Administration | e ahoo...@bmjgroup.com
BMJ Technology, BMJ Publishing Group | t +44 20 7383 6049
BMA House, LONDON, WC1H 9JR |
___
The BMJ Group is one of the world's most trusted providers of medical
information for doctors, researchers, health care workers and patients
www.bmjgroup.bmj.com. This email and any attachments are confidential. If you
have received this email in error, please delete it and kindly notify us. If
the email contains personal views then the BMJ Group accepts no responsibility
for these statements. The recipient should check this email and attachments
for viruses because the BMJ Group accepts no liability for any damage caused by
viruses. Emails sent or received by the BMJ Group may be monitored for size,
traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ
Group. A private limited company, registered in England and Wales under
registration number 03102371. Registered office: BMA House, Tavistock Square,
London WC1H 9JR, UK.
___
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
