How to report a bug¶

The lighttpd issue tracker is for issues in lighttpd, not for user questions.
Please direct questions to the Forums

If you find a bug in lighttpd you can help a lot to find a fix for it by following some simple steps:

• Don't Panic
• For support questions (How do I... ?), please use the Forums!
• If you are new to lighttpd or have a question, then there is most likely not an issue in lighttpd, i.e. not a bug. Please use the Forums!
• Please report bugs in lighttpd in the lighttpd issue tracker (and please direct questions to the Forums)

Writing a bug report¶

Before opening a new issue, please check if someone else already reported the problem in the lighttpd issue tracker Be sure to search recent already-closed issues.

If this is a new bug, please open a new issue

• If lighttpd behaves in an unexpected way, please prepare an strace (see directions below)
• If lighttpd crashes, please try to generate a backtrace (see directions below)
• If you have generated a syscall-trace (strace) or a backtrace please make sure that you can reproduce the problem. Otherwise it will be really hard for the developers to fix the problem for you.
• If you feel that you should not make a bug report public, please send email to: security (at) lighttpd (dot) net

strace¶

strace is the name of the syscall-tracer on Linux. Every Unix-like OS provides a utility to collect information about system call like open, write, close and so on.

They have different names like

• strace
• truss
• ktrace (then kdump to get output)

If strace is available it is prefered as it provides the most useful information. Execute it like:

strace -olighttpd.trace -tt -s 4000 lighttpd -D -f ./lighttpd.conf 

It will generate a file called lighttpd.trace.

If you have a running instance of lighttpd and want to see what lighttpd is doing you can attach strace to the process:

strace -olighttpd.trace -tt -s 4000 -p $pidof-lighttpd

Alternatively, if you want to debug a possible problem in lighttpd that is not related to networking and doing so on a busy server, try this:

strace -tt -s 4000 -etrace='!open,epoll_wait,epoll_ctl,sendfile64,read,fcntl,write,fcntl64,
close,time,stat64,stat,writev,setsockopt,accept,getsockname,ioctl,socket,connect' \
 -p $pidof-lighttpd

The above would tell strace to exclude the system calls listed from the trace, thus reducing the performance impact on lighttpd as well as producing much less output that may actually not be necessary in order to debug the problem at hand.

ktrace¶

On all BSDs incl. MacOS X you can use ktrace as replacement for strace. The output not as informative as strace, but still very important for tracking down problems.

ktrace will, once enabled, trace data until the process exists or the trace point is cleared. A traced process can generate enormous amounts of log data quickly; it is strongly suggested that users memorize how to disable tracing before attempting to trace a process. The following command is sufficient to disable tracing on all user owned processes, and, if executed by root, all processes.

ktrace -C

To enable tracing run:

ktrace -p <lighttpd pid> -f lighttpd.trace

to attach to the process.

Use kdump to get useful data:

kdump -f lighttpd.trace -T -m 4000 -d

For more ways on limiting the output and such, see
http://www.openbsd.org/cgi-bin/man.cgi?query=ktrace and
http://www.openbsd.org/cgi-bin/man.cgi?query=kdump

Backtrace¶

A backtrace is a trace of the function which have been called before lighttpd died.

The best way to generate such a backtrace is using valgrind:

valgrind --tool=memcheck -v --log-file=lighttpd --num-callers=8 lighttpd -D -f ./lighttpd.conf

valgrind does many useful things while it waits for the server to crash:

• checks for uninitialized variables
• checks for out-of-bounds access
• and many more

valgrind does not normally produce large log files and does not seem to degrade lighttpd's throughput much. Meaning, it's a very good alternative when debugging on busy servers as compared to strace.

If you can't use valgrind there is another way to generate a backtrace:

$ gdb lighttpd
(gdb) handle SIGPIPE pass nostop noprint
(gdb) r -D -f lighttpd.conf
...
(gdb) bt

Memleaks¶

If you experience that lighttpd is using more than 1Gb of RAM you might have spotted a memleak. Valgrind, our valuable helper, can help you to provide the necessary information to fix it.

valgrind --tool=memcheck -v --log-file=lighttpd --num-callers=8 \
  --leak-check=yes --show-reachable=yes \
  lighttpd -D -f ./lighttpd.conf

Beware that this will use alot of memory and will slow down the process. You might not be able to run this on a production system with real load.