1. 问题背景
登录请求URL:
Request URL:
https://www.xxxxxx.com/wp-login.php
返回的响应头信息是:
location:
https://www.xxxxxx.com/wp-admin/
证明登录成功。
接下来浏览器自动跳转, 请求头信息是:
Request URL: https://www.xxxxxx.com/wp-admin/
Request Method: GET
Status Code: 302 Found
Remote Address: 8.210.93.167:443
Referrer Policy: strict-origin-when-cross-origin
结果响应信息变成这样:
location:
https://www.xxxxxx.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.xxxxxx.com%2Fwp-admin%2F&reauth=1
再次要求登录。
试了很多次，都是一样的结果。
2. 解决方案搜索
使用搜索引擎，搜索关键字: wordpress 不能登录。
找到一篇知乎的文章:
尝试了里面提供的多种方法， 都不能解决，还是同样的错误。
3. 问题定位
既然处理不了，那就看看Nginx日志是否报错。
# 进入Nginx日志目录
cd /var/log/nginx/
# 查看当前目录下的文件列表
# ls -l
ll
# 这里发现了一个197MB的错误日志文件
# -rw-r--r-- 1 nginx nginx 197636096 5月 13 11:27 error.log
# 查看
tail -n 100 error.log
结果, 在这里发现了很多条类似的错误日志。
摘录如下:
2025/05/13 11:19:26 [error] 16175#0: *10189413 FastCGI sent in stderr: "PHP message: WordPress数据库查询SHOW FULL COLUMNS FROM `wp_options`时发生Disk full (/tmp/#sql_543_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")错误，这是由require('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, wp_cron, spawn_cron, set_transient, update_option查询的
PHP message: WordPress数据库查询SHOW FULL COLUMNS FROM `wp_usermeta`时发生Disk full (/tmp/#sql_543_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")错误，这是由wp_signon, wp_set_auth_cookie, WP_Session_Tokens->create, WP_Session_Tokens->update, WP_User_Meta_Session_Tokens->update_session, WP_User_Meta_Session_Tokens->update_sessions, update_user_meta, update_metadata查询的" while reading response header from upstream, client: 183.225.154.250, server: xxxxxx.com, request: "POST /wp-login.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.xxxxxx.com", referrer: q^C
找到其中的关键原因, Disk full, 也就是磁盘满了。
使用 df -h 命令查看:
# 查看磁盘使用情况
df -h
# 文件系统 容量 已用 可用 已用% 挂载点
# /dev/vda1 40G 38G 0 100% /
确认是磁盘空间占满导致的问题。
4. 排查过程
磁盘空间用满, 或者内存空间溢出, 是很多服务器端故障问题的原因。
排查问题时, 可以优先排查这一类问题。
我们可以使用 du -sh 命令来辅助进行磁盘空间占用情况排查, 以查看各个目录占用的空间。
# 进入需要排查的目录
cd /
# 查看当前目录下的磁盘空间占用情况
du -sh *
得到的结果大致如下:
2.1G data
1.6G root
23G usr
9.3G var
简单分析, 这里的情况是：
/usr目录占用了 23GB/var目录占用了 9.3GB
有了这个信息, 我们就可以依次进入各个目录, 排查到底是哪些文件或目录占用了磁盘空间。
# 依次进入各个子目录排查
cd /usr/
du -sh *
cd /usr/local/
du -sh *
# 发现了一个目录使用的磁盘空间较多
# 17G www
cd /usr/local/www
du -sh *
# 继续往下查找
# 17G tomcat-8.0.48
cd /usr/local/www/tomcat-8.0.48
du -sh *
# 17G logs
# 继续往下排查
cd /usr/local/www/tomcat-8.0.48/logs/
# 查看文件列表
ll
通过 ll 命令, 发现该目录下有大量的文件,
这里列出部分:
ll
总用量 5129216
-rw-r--r-- 1 root root 6955733 11月 1 2020 access_log.2020-11-01.txt
-rw-r--r-- 1 root root 6956111 11月 3 2020 access_log.2020-11-02.txt
......
-rw-r--r-- 1 root root 250140 5月 12 23:44 access_log.2025-05-12.txt
-rw-r--r-- 1 root root 44236 5月 13 11:36 access_log.2025-05-13.txt
-rw-r--r-- 1 root root 1115 11月 1 2020 catalina.2020-11-01.log
-rw-r--r-- 1 root root 3580 11月 2 2020 catalina.2020-11-02.log
......
-rw-r--r-- 1 root root 6473 5月 11 21:05 catalina.2025-05-11.log
-rw-r--r-- 1 root root 8669 5月 12 23:18 catalina.2025-05-12.log
-rw-r--r-- 1 root root 1198692264 5月 13 11:36 catalina.out
-rw-r--r-- 1 root root 2671361318 5月 13 11:36 gc.log
-rw-r--r-- 1 root root 5527 11月 1 2020 localhost.2020-11-01.log
-rw-r--r-- 1 root root 4950 11月 3 2020 localhost.2020-11-03.log
......
-rw-r--r-- 1 root root 5887 5月 12 07:32 localhost.2025-05-12.log
-rw-r--r-- 1 root root 5887 5月 13 06:53 localhost.2025-05-13.log
可以看到:
catalina.out文件的大小是1198692264, 大约 1.1GB.gc.log文件的大小是2671361318, 大约 2.6GB.- 此外, 还有大量的从 2020 年开始的 Tomcat 日志。
5. 清理空间
确实是很久没有清理日志文件了。
如果是生产环境，那么一般会配置定期归档或清理的命令。
这里因为是个人站点, 所以直接把比较老的文件删除即可。
# 进入目标目录
cd /usr/local/www/tomcat-8.0.48/logs/
# 列出文件列表
ll
# 执行清理
# rm -f localhost.2025-04* localhost.2025-03*
# rm -f localhost.2025-02* localhost.2025-01*
# rm -f localhost.2024* localhost.2023* localhost.2022*
# rm -f localhost.2021* localhost.2020*
# 继续列出文件列表
ll
# 继续执行清理
# rm -f catalina.2025-04* catalina.2025-03*
# rm -f catalina.2025-02* catalina.2025-01*
# rm -f catalina.2024* catalina.2023* catalina.2022*
# rm -f catalina.2021* catalina.2020*
# 继续列出文件列表
ll
# 继续执行清理
# rm -f access_log.2025-04* access_log.2025-03*
# rm -f access_log.2025-02* access_log.2025-01*
# rm -f access_log.2024* access_log.2023* access_log.2022*
# rm -f access_log.2021* access_log.2020*
6. 处理结果
在浏览器重新页面，登录成功。 此问题处理完成。
7. 后续优化
如果是持续运维和升级的系统，一般不会有这么大的日志文件。
如果是容器化的部署系统，也会有很多类似的清理脚本来辅助运行。
为了防止出现类型情况, 需要执行一些优化操作:
-
- 设置JVM的GC日志大小和滚动策略。 比如这篇文章:
-
- 设置日志定期清理任务, 比如清理3个月之前的，满足特定前缀的日志文件。
-
catalina.out文件切割或清空。