1.1.1 progress

[Janis Putrams]

Hi!

With "master crash log" i meant output of varnishlog when management process dies.

Anyway I wanted to capture core file so run varnishd in foreground.

I set 
CXXFLAGS="-g"
LDFLAGS="-g"
in configure.ac. then run
./configure --prefix=/usr --enable-debug && make clean && make

05:17:28 root[pts/0]@slow ~# ulimit -a|grep core
core file size          (blocks, -c) 650000


08:06:24 root[pts/0]@slow ~# varnishd -d -d -f /etc/varnishd/varnishd.conf -T 127.0.0.1:81 -P /var/run/varnishd.pid
file /var/spool/varnishd/varnishd_storage.bin size 536870912 bytes (131072 fs-blocks, 131072 pages)
Using old SHMFILE
rolling(1)...
rolling(2)...
start
CLI <start>
start child pid 23327
200 0

Child said (2, 23327): <<Child starts
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 23327): <<socktest: linger=0 sndtimeo=0 rcvtimeo=0
>>
Cache child died pid=23327 status=0xb
Clean child
Child cleaned
start child pid 23404
Child said (2, 23404): <<Child starts
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 23404): <<socktest: linger=0 sndtimeo=0 rcvtimeo=0
>>
Cache child died pid=23404 status=0xb
Clean child
Child cleaned
start child pid 23484
...
>>
Child said (2, 28871): <<socktest: linger=0 sndtimeo=0 rcvtimeo=0
>>
Cache child died pid=28871 status=0xb
Clean child
Child cleaned
start child pid 28900
Child said (2, 28900): <<Child starts
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 28900): <<socktest: linger=0 sndtimeo=0 rcvtimeo=0
>>
Cache child died pid=28900 status=0xb
Clean child
Child cleaned
start child pid 28936
Pushing vcls failed:
CLI communication error
Child said (1, 28936): <<Child starts
>>
unlink ./bin.XXQ9wDR6
14:00:53 root[pts/0]@slow ~#

Though I found no core file after this. Please suggest what could I do to trace it.

Thanks,
Janis

On Saturday 18 August 2007 13:39, Dag-Erling Smørgrav wrote:
> Janis Putrams <janis.putrams at delfi.lv> writes:
> > I have been running varnishd from svn @Aug 16 06:17 and I managed to
> > capture master crash log.
>
> I have no idea what a "master crash log" is, but the varnish log you
> included is corrupted and doesn't tell me much, except that most of
> your traffic is piped to the backend rather than cached.  If you're
> having trouble with the management and / or worker process crashing,
> you should run varnish in the foreground (-d -d) to capture the error
> messages (most likely assertion failures), and get a backtrace.
>
> DES