正文

创建AWStats专用数据目录，并赋予www用户完全控制权

节点老杨
节点老杨 V管理员 /66阅读/3评论
0723
文章最后更新时间2026年07月23日，若文章内容或图片失效，请留言反馈！

宝塔面板AWStats插件踩坑实录：从“数据全红”到“稳如老狗”的血泪史

深夜的红色警报

那天凌晨两点,我正窝在沙发上刷手机，突然接到客户连环夺命call：“网站后台全是红色报错！AWStats统计数据出不来，老板明天要汇报！”

我睡眼惺忪地打开宝塔面板,点进AWStats插件页面——好家伙，整个界面像被泼了红油漆，满屏的“错误：无法读取日志文件”“错误：数据库连接失败”，再看服务器资源监控，CPU占用率飙到95%，内存快被吃干抹净。

作为用了五年宝塔的老运维,我第一反应是：这破插件又抽风了，但这次明显不对劲——之前AWStats虽然偶尔卡顿，但从未出现过全盘报错的情况。

创建AWStats专用数据目录，并赋予www用户完全控制权

创建AWStats专用数据目录，并赋予www用户完全控制权

扒开“事故现场”

我连上SSH,先查日志。tail -100 /www/server/panel/logs/error.log 里密密麻麻都是这样的内容：

[error] [client 127.0.0.1] File does not exist: /www/wwwlogs/access_log
[error] AWStats core: Error: Couldn't open server log file /www/wwwlogs/access_log : Permission denied
[error] AWStats database connect failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock'

等等,access_log不存在？我cd到日志目录，ls -la一看——access_log确实在，但所有者是www用户，权限644，可AWStats进程运行时用的是root？不，等会儿，我记得宝塔的AWStats插件是跑在cron里的，但具体用户呢？

我ps aux | grep awstats一看，进程居然是以root身份在跑！这就离谱了——root去读www用户的文件，权限没问题啊，但为什么报Permission denied？

我试着手动执行命令：sudo -u www /www/server/panel/plugin/awstats/awstats.pl -config=xxx，结果命令行里报错信息更清晰了：

Error: Unable to create directory /www/wwwlogs/awstats (Permission denied)

原来问题在这里！AWStats默认会在日志目录下创建缓存目录和数据库文件，但/www/wwwlogs的权限是755，所有者是www，root用户进去反而写不进去文件——因为目录上没有setgid位，root创建的文件归属root，但后续进程以www用户运行时又读不了root创建的文件。

排查思路：从表象看本质

先梳理一下报错的逻辑链：

  1. 日志文件读取失败：表面是文件不存在或权限拒绝，实则是AWStats进程用户与日志文件用户不一致。
  2. 数据库连接失败：报MySQL socket连接问题，但我的MySQL明明正常运行，后来发现是AWStats插件自带的SQLite数据库被锁住了，因为多个cron进程同时读写导致。
  3. CPU飙升：多个AWStats进程同时运行，互相竞争日志文件，死循环了。

我检查了cron配置：crontab -l | grep awstats，发现竟然有两条记录：

*/5 * * * * /www/server/panel/plugin/awstats/awstats.pl -config=site1
*/5 * * * * /www/server/panel/plugin/awstats/awstats.pl -config=site2

而宝塔AWStats的默认设置里,每个站点都独立设置了cron任务，但时间没有错开，导致同一时间点并发执行。

解决方案：三管齐下

修复权限和目录

chown www:www /www/server/awstats_data
chmod 755 /www/server/awstats_data
# 修改AWStats配置文件，指定数据目录
sed -i 's#DirData="/www/wwwlogs/awstats"#DirData="/www/server/awstats_data"#g' /www/server/panel/plugin/awstats/awstats.xxx.conf

规范cron任务

# 删除所有旧的cron任务
crontab -r
# 重新添加，每个站点间隔1分钟执行，避免并发
*/5 * * * * sleep 0 && /www/server/panel/plugin/awstats/awstats.pl -config=site1
*/5 * * * * sleep 60 && /www/server/panel/plugin/awstats/awstats.pl -config=site2
# 如果有更多站点，依次增加sleep时间

清理死锁进程

# 杀掉所有残留的awstats进程
pkill -f awstats
# 删除可能损坏的锁文件
find /www/server/awstats_data -name "*.lock" -delete
find /www/server/awstats_data -name "*.pid" -delete

预防建议：别让噩梦再来

经过这次“红色预警”，我总结了几条铁律，兄弟们可以直接抄作业：

安装后立刻改配置 宝塔默认的AWStats配置就是个深坑，装完插件后，先进设置页面，把“日志文件位置”从/www/wwwlogs/access_log改为自定义目录，比如/data/wwwlogs/，然后切记！别用默认的root运行，在“运行用户”处选择www。

分散cron时间
宝塔的“自动更新”功能会一次性给所有站点设置相同cron时间段，正确做法是：进入“计划任务”，手动创建cron，给每个站点设置不同的分钟偏移，比如站点A在第5分钟，站点B在第10分钟，以此类推，或者直接用sleep命令错开，就像我上面写的。

日志轮替要同步
AWStats依赖日志文件连续性，如果你用了宝塔的日志切割（logrotate），务必在切割后触发AWStats重建统计，在logrotate配置文件中加上：

postrotate
    /www/server/panel/plugin/awstats/awstats.pl -config=site1 -update >/dev/null 2>&1
endscript

否则切割后日志编号变了,AWStats会抓瞎。

监控数据库健康
AWStats使用SQLite存储统计，SQLite不支持并发写入，如果流量大，建议把数据库改成MySQL，在配置文件中修改：

LoadPlugin="mysql"
...
DbPass="你的密码"

注意提前在宝塔面板中创建数据库和用户。

最狠的一招：直接换工具
如果站点访问量超过每天5万IP，AWStats基本是给自己找罪受，这时候可以考虑迁移到Matomo（自建）或百度统计（免费），宝塔应用商城里有Matomo一键部署，装完直接替换AWStats，功能强N倍，还不闹脾气。

后续：从费心到省心

那次折腾完已经凌晨四点,但看到AWStats界面从一片血红变成正常的蓝色图表，客户邮件也自动生成了，心里还是爽的，后来我把这套方案写进运维手册，再也没出过事。

其实AWStats本身是靠谱的,只是宝塔插件版本的默认配置太坑，只要捋顺了用户权限、cron调度、日志轮替这三个关键点，它就是个安静的美男子，但如果你跟我一样，不想每天提心吊胆看红色警告，趁早迁移到Matomo，毕竟，运维的时间是用来喝咖啡的，不是用来当消防员的。