如何报告错误¶

lighttpd 问题跟踪器 用于跟踪 lighttpd 中的问题，而非用户提问。
请将问题发送到论坛

如果您在 lighttpd 中发现错误，可以通过遵循一些简单的步骤来帮助找到解决方案

• 不要惊慌
• 对于支持问题（我该如何...？），请使用论坛！
• 如果您是 lighttpd 的新用户或有疑问，那么 lighttpd 很可能没有问题，即不是错误。请使用论坛！
• 请在lighttpd 问题跟踪器中报告 lighttpd 的错误（并且请将问题发送到论坛）

撰写错误报告¶

在提出新问题之前，请检查是否有人已经在lighttpd 问题跟踪器中报告了此问题。请务必搜索最近已关闭的问题。

如果这是一个新错误，请提出一个新问题

• 如果 lighttpd 行为异常，请准备一个 strace（参见以下说明）
• 如果 lighttpd 崩溃，请尝试生成一个回溯（参见以下说明）
• 如果您生成了 syscall-trace (strace) 或回溯，请确保您可以重现该问题。否则，开发人员将很难为您解决问题。
• 如果您认为不应公开错误报告，请发送电子邮件至：security (at) lighttpd (dot) net

strace¶

strace 是 Linux 上 syscall-tracer 的名称。每个类 Unix 操作系统都提供一个工具来收集有关系统调用（如 open、write、close 等）的信息。

它们有不同的名称，例如：

• strace
• truss
• ktrace（然后使用 kdump 获取输出）

如果 strace 可用，则首选它，因为它提供了最有用的信息。执行方式如下：

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

它将生成一个名为 lighttpd.trace 的文件。

如果您有正在运行的 lighttpd 实例，并想查看 lighttpd 正在做什么，可以将 strace 附加到该进程：

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

或者，如果您想调试 lighttpd 中可能与网络无关的问题，并且是在繁忙的服务器上进行，请尝试此操作：

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

上述命令将告诉 strace 从跟踪中排除列出的系统调用，从而减少对 lighttpd 的性能影响，并减少可能不需要的输出，以便调试当前问题。

ktrace¶

在包括 MacOS X 在内的所有 BSD 系统上，您可以使用 ktrace 作为 strace 的替代。其输出不如 strace 信息丰富，但对于追踪问题仍然非常重要。

ktrace 一旦启用，将跟踪数据直到进程退出或跟踪点被清除。被跟踪的进程可以快速生成大量日志数据；强烈建议用户在尝试跟踪进程之前记住如何禁用跟踪。以下命令足以禁用所有用户拥有进程的跟踪，如果由 root 执行，则禁用所有进程的跟踪。

ktrace -C

要启用跟踪，请运行：

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

附加到进程。

使用 kdump 获取有用数据：

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

有关限制输出等更多方法，请参阅：
http://www.openbsd.org/cgi-bin/man.cgi?query=ktrace 和
http://www.openbsd.org/cgi-bin/man.cgi?query=kdump

回溯¶

回溯是 lighttpd 崩溃之前已调用的函数跟踪。

生成此类回溯的最佳方法是使用 valgrind

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

valgrind 在等待服务器崩溃时执行许多有用的操作：

• 检查未初始化的变量
• 检查越界访问
• 以及更多

valgrind 通常不会产生大型日志文件，并且似乎不会严重降低 lighttpd 的吞吐量。这意味着，与 strace 相比，在繁忙的服务器上进行调试时，它是一个非常好的替代方案。

如果您无法使用 valgrind，还有另一种方法可以生成回溯：

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

内存泄漏¶

如果您发现 lighttpd 占用了超过 1GB 的 RAM，您可能发现了内存泄漏。Valgrind，我们宝贵的帮手，可以帮助您提供修复它所需的信息。

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

请注意，这将占用大量内存并减慢进程速度。您可能无法在实际负载下的生产系统上运行此操作。