http://www.snooda.com/category/5/---lighttpd 开发调试

lighttpd中handle_start_backend钩子（hook）函数的理解 

[ |   2012/04/25 19:59]

  大 |  中 |  小 

    之前按字面意思理解handle_start_backend是说连接后端服务端口（webserver，fastcgi等等），今天发现并非如此。
    这个hook是在CON_STATE_HANDLE_REQUEST_HEADER状态时，
如果con->mode仍旧是DIRECT类型且con->physical.path为空，会先调用：
plugins_call_handle_uri_raw
plugins_call_handle_uri_clean
plugins_call_handle_docroot
plugins_call_handle_physical

如果con->mode还是DIRECT，那么会判断con->physical.path指定的文件是否存在，
    若存在，如果是软链但是con->conf.follow_symlink为0，那么403，如果是目录但请求url不是路径名，则301跳转到目录路径（在末尾加/）
    若无权限访问，返回403
    若找不到文件，返回404
    若ENOTDIR（对文件做了目录操作），则考虑path_info
    若EMFILE（进程句柄不足），则返回HANDLER_WAIT_FOR_FD
    若不是以上情况，打印错误日志，返回500


如果con->physical.path存在且无错误发生，或为ENOTDIR，那么又判断了一次是否存在（这里代码设计比较恶心）
    如果是普通文件且没有软链问题，那么break出去执行plugins_call_handle_start_backend。
    反之则一直向上遍历，直到遍历到一个真实存在的文件，如果找不到，那么404，如果找到了，将pathinfo串放入con->request.pathinfo。然后截短con->uri.path。

然后才会去调用plugins_call_handle_start_backend。
所以对于很多动态请求是不会调用plugins_call_handle_start_backend的。

这个钩子被mod_access调用用来实现deny_all功能。
被mod_indexfile调用用来实现默认文件功能（请求/时映射到index.php等）

lighttpd日志切分  

 之前在读代码的时候发现lighttpd在收到SIGHUP信号后会把日志重新打开一下，一直没有理解这么做的意义是什么。今天终于用到了这个功能。
    一个新模块没有使用cronlog等日志切分工具，直接打印日志到文件，（使用管道切分日志有风险，被打印程序一旦hang住，lighttpd也就卡住了），但如何切分日志文件就变成了一个问题。mv的话由于不改变inode，还是往同一个文件打。cp代价太大。直接清空日志的话又太粗暴。这里就用到了sighup功能。只要将文件mv到新名字，然后用killall -s SIGHUP lighttpd，这样lighttpd就会自动重新打开lighttpd.log打印了。

由一个503问题看配置文件重要性 

[ |   2012/02/26 23:55]

  大 |  中 |  小 

    最近有一个困扰近两个月的bug终于解决了，心情愉快。503问题之前一直没找到头绪，压力一大就开始有，越大就越多。刚开始一直认为503是正常现象，后端负载能力不足的必然结果。加之之前后端用的自己写的模拟server，性能什么的没什么保证。所以一直在看是不是程序逻辑上有什么漏洞会导致封禁所有后端，一直找不到头绪。

    周五测试同学突然说：现在用的后端server肯定能力要强于前边这个啊，怎么可能会因为负载力不足导致503呢？一想确实啊，肯定是流量调度部分的问题。开gdb仔细一找，结果大跌眼镜，原来是跟后端的连接池的最大允许并发连接数开的太小了。。

    之前那个值设置的比较小是有道理的，因为php是每个进程处理一个请求的，所以并发数肯定不会超过启动的php进程数。但现在后端改用了lighttpd，lighttpd可以承载的并发数是很多的，这样的话在高并发请求的情况下后端连接池很容易就用完了。

    由此有两个感触，一是不同场景下配置项一定要仔细想想如何调优。二是bug并不都是逻辑错误导致的，还有可能是配置错了。。。

lighttpd打印日志出core的问题 

[ |   2012/06/15 17:17]

  大 |  中 |  小 

    有一个问题，是在一个环境上的lighttpd一打日志就出core，很奇怪，看堆栈信息是出在mod_accesslog里，今天看了下，发现原来是试图打印%i导致的。
    lighttpd支持在日志中打印请求头中的字段，方法是%{key}i，这样就能在请求头中的key字段打印到日志里，打印referer等东西的时候比较方便。

    但如果直接写%i的话，由于没有指定key，导致NULL指针，lighttpd没有校验导致出core。

    恰好%I是打印请求长度，大写I还是比较容易误按成小写的。所以有了这个问题

lighttpd中CONST_STR_LEN的用法 

[ |   2012/07/05 19:49]

  大 |  中 |  小 

    今天遇到一个问题，在获取http头的时候怎么也获取不到，手动core出来和gdb上去调试发现都是空的，应该是开了O2优化的缘故，于是在程序中打印http头，正常。

    不得已，单步gdb进匹配函数里，发现一个四字符的key值长度被判定为8，很奇怪，查代码原来是用了个CONST_STR_LEN来代替了本来应该填ptr, strlen(ptr)的位置。而CONST_STR_LEN是一个宏，内容为：x, x ? sizeof(x) - 1 : 0。显然，如果传一个指针进去的话，sizeof指针的结果是8（字节，x64)，这个宏只能在内容是字符串常量的时候用，不可以用在指针上。当时用的时候看lighttpd代码中一些地方用了这个宏，于是想当然认为到处都可用。。看来还是要注意一些。