“Linux运维常见故障”的版本间的差异
跳到导航
跳到搜索
小 （导入1个版本） |
|||
| 第36行： | 第36行： | ||
</pre> | </pre> | ||
| + | =web故障= | ||
| + | <pre> | ||
| + | 个人wiki打开500 | ||
| + | 在上面 curl ip.sb 也是 应该 是CDN问题,反正我直接host 没事了 | ||
| + | |||
| + | curl ip.sb | ||
| + | <html> | ||
| + | <head><title>500 Internal Server Error</title></head> | ||
| + | <body bgcolor="white"> | ||
| + | <center><h1>500 Internal Server Error</h1></center> | ||
| + | <hr><center>nginx</center> | ||
| + | </body> | ||
| + | </html> | ||
| + | |||
| + | </pre> | ||
=see also= | =see also= | ||
[https://blog.csdn.net/u011001084/article/details/79419721 关于Linux运维常见故障排查和处理的33个技巧汇总] | [https://blog.csdn.net/u011001084/article/details/79419721 关于Linux运维常见故障排查和处理的33个技巧汇总] | ||
[[category:ops]] | [[category:ops]] | ||
2022年6月21日 (二) 07:05的最新版本
crontab输出结果控制
问题： /var/spool/clientmqueue目录占用空间超过100G 原因： cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了/var/spool/clientmqueue目录下的那些文件，日积月累可能撑破磁盘。 解决： 1）直接手动删除：ls|xargsrm-f； 2）彻底解决：在cron的自动执行语句后加上>/dev/null2>&1
文件删了磁盘空间没释放
问题： 某天发现某台机器df-h已用磁盘空间为90G，而du-sh/*显示所有使用空间加起来才30G，囧。 原因： 可能某人直接用rm删除某个正在写的文件，导致文件删了但磁盘空间没释放的问题 解决： 1）最简单重启系统或者重启相关服务。 2）干掉进程 /usr/sbin/lsof|grepdeleted ora25575data33uREG65,654294983680/oradata/DATAPRE/UNDOTBS009.dbf(deleted) 从lsof的输出中，我们可以发现pid为25575的进程持有着以文件描述号（fd）为33打开的文件/oradata/DATAPRE/UNDOTBS009.dbf。在我们找到了这个文件之后可以通过结束进程的方式来释放被占用的空间：echo>/proc/25575/fd/33 3）删除正在写的文件一般用cat/dev/null>file
web故障
个人wiki打开500 在上面 curl ip.sb 也是 应该 是CDN问题,反正我直接host 没事了 curl ip.sb <html> <head><title>500 Internal Server Error</title></head> <body bgcolor="white"> <center><h1>500 Internal Server Error</h1></center> <hr><center>nginx</center> </body> </html>
