FW: Varnish on a pi
Joshua Small
JSmall at daraco.com.au
Thu Jan 3 07:17:08 CET 2013
Hi,
Just to add to below, I've replicated this on the latest trunk.
I've also confirmed that the flag that the -enable-debugging-symbols doesn't matter - it's the -enable-diagnostics that makes the difference between a working installation and segfaulting installation.
I can see that this appends a CFLAG -DDIAGNOSTICS to the build - but can't for the life of me see what this actually does to the operation of the service.
If anyone can shed some light on where exactly this flag is used (I've done a lot of grepping to not much avail) I'd be keen to investigate it.
From: varnish-misc-bounces at varnish-cache.org [mailto:varnish-misc-bounces at varnish-cache.org] On Behalf Of Joshua Small
Sent: Thursday, 3 January 2013 1:19 PM
To: varnish-misc at varnish-cache.org
Subject: Varnish on a pi
Hi,
I've trying to install Varnish on a Raspberry pi. This has been discussed on their own forums with a general view of "it simply doesn't work", so I set about finding why.
Some info:
pi at raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #4 PREEMPT Fri Dec 28 16:14:38 EST 2012 armv6l GNU/Linux
pi at raspberrypi ~ $ free
total used free shared buffers cached
Mem: 497132 284352 212780 0 63616 180780
-/+ buffers/cache: 39956 457176
Swap: 102396 0 102396
Image is the Debian port "raspbian", updated from repositories as of today.
I initially assumed the repositories were the issue and obtained varnish-3.0.3 from source. The install is fairly default, documented here:
sudo apt-get install automake libtool
sh autogen.sh
sh configure
make
sudo make install
sudo vi /usr/local/etc/varnish/default.vcl
Setup backend servers..
sudo ldconfig -n /usr/local/lib/
Varnish however, appears to crash and burn:
pi at raspberrypi ~ $ sudo /usr/local/sbin/varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,16M -a 172.31.1.50:80 -d
Platform: Linux,3.2.27+,armv6l,-sfile,-smalloc,-hcritbit
200 233
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.2.27+,armv6l,-sfile,-smalloc,-hcritbit
Type 'help' for command list.
Type 'quit' to close CLI session.
Type 'start' to launch worker process.
start
child (19755) Started
Pushing vcls failed:
CLI communication error (hdr)
Stopping Child
200 0
Child (19755) died signal=11
Child cleanup complete
quit
500 22
Closing CLI connection
In order to follow the recommended process here https://www.varnish-cache.org/trac/wiki/DebuggingVarnish, I reconfigured with --enable-debugging-symbols --enable-diagnostics.
I went back and forth between a "default" install and "diagnostic" install three different times to confirm this, because I appreciate it doesn't seem plausible. Regrettably, the situation experienced is that I have a fix: Compile in diagnostic mode. With the above configure options (I ran make clean between each new build) the Varnish service appeared to operate fine.
Whilst I could just leave diagnostics on, I'm assuming there's load associated with this. I've pasted below an strace of the crashed system, but I'm just not sure how else I can debug in this situation. Is there anything else that the diagnostics mode does that could possibly get involved here?
[pid 18164] clock_gettime(CLOCK_REALTIME, <unfinished ...>
[pid 18166] <... nanosleep resumed> NULL) = 0
[pid 18166] mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x45e00000
[pid 18166] mprotect(0x45e00000, 4096, PROT_NONE) = 0
[pid 18166] clone(Process 18173 attached (waiting for parent)
Process 18173 resumed (parent 18166 ready)
child_stack=0x45e0efa8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x45e0f4d8, tls=0x45e0f930, child_tidptr=0x45e0f4d8) = 18173
[pid 18173] set_robust_list(0x45e0f4e0, 0xc) = 0
[pid 18173] clock_gettime(CLOCK_REALTIME, {1357176395, 646464764}) = 0
[pid 18173] futex(0x45e0ebd4, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 18166] nanosleep({0, 2000000}, <unfinished ...>
[pid 18164] <... clock_gettime resumed> {1357176395, 642222934}) = 0
[pid 18164] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 18164 detached
[pid 18173] +++ killed by SIGSEGV +++
Below you can see the syslog that covers me starting varnish twice, once with a default configure, once with the diagnostics enabled.
Jan 3 12:54:27 raspberrypi varnishd[26807]: Platform: Linux,3.2.27+,armv6l,-smalloc,-smalloc,-hcritbit
Jan 3 12:54:27 raspberrypi varnishd[26807]: child (26808) Started
Jan 3 12:54:27 raspberrypi varnishd[26807]: Child (26808) died signal=11
Jan 3 12:54:27 raspberrypi varnishd[26807]: Child (-1) said Child starts
Jan 3 13:05:04 raspberrypi varnishd[31536]: Platform: Linux,3.2.27+,armv6l,-smalloc,-smalloc,-hcritbit
Jan 3 13:05:04 raspberrypi varnishd[31536]: child (31537) Started
Jan 3 13:05:04 raspberrypi varnishd[31536]: Child (31537) said Child starts
Finally, some info from the config log.
pi at raspberrypi ~/varnish-3.0.3 $ grep -i warn config.log
cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C [enabled by default]
configure:13219: WARNING: xsltproc not found - not building documentation
configure:13279: WARNING: rst2man not found - not building man pages
configure:13342: WARNING: rst2html not found - not building changelog
conftest.c:40:6: warning: conflicting types for built-in function 'cos' [enabled by default]
configure:14290: WARNING: libedit not found, disabling libedit support
conftest.c:72:6: warning: conflicting types for built-in function 'vprintf' [enabled by default]
configure:15220: WARNING: won't look for sendfile() on armv6l-unknown-linux-gnueabihf
conftest.c:68:3: warning: left shift count >= width of type [enabled by default]
conftest.c:68:3: warning: left shift count >= width of type [enabled by default]
conftest.c:69:10: warning: left shift count >= width of type [enabled by default]
conftest.c:69:10: warning: left shift count >= width of type [enabled by default]
Sorry for the long post - but hopefully it gives us something to go on. Any information would be appreciated.
-Josh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20130103/f257c1dc/attachment-0001.html>
More information about the varnish-misc
mailing list