ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

暑假运维学习打卡第二十八天8.28

暑假运维学习打卡第二十八天8.28 前记大家好呀中间停更了十天左右主要是中途对自己的学习路线有点迷茫了。家里人一直在催我对毕业后的去向早点做规划他们的想法是几乎一定要让我去读研坚定的认为现在没有一个研究生学历就找不到一个能养活自己的工作总之就是主包现在的第一优先级只能是考研了找工作在他们口中只能是没考上研的次选于是主包就对学习linux产生了一些动摇在大三大部分时间都要投入考研而且考虑到学分还没修满还有挺多课没有修的情况下在大三有空实习的可能性感觉也不大了。但最后可能心里还是咽不下那口气吧还是决定得继续学下去就算后面可能没有充足的时间准备也希望自己每天能匀出1个小时的时间学习相关知识。这段时间也让我反思了自己的学习路线之前过linux基础命令时太快过于囫囵吞枣基本都只是打了个照面对某个命令具体能用于什么场景以及实际工作中有什么应用场景要用什么命令还是没有一个概念。于是决定把学习节奏慢下来从基础的linux命令开始向深学习理解每天争取能学透一个工作中会遇到的案例情况掌握相关命令在实际工作中的用途通过一点点积累保持学习也算是给自己考研失败后留一条备选的路不过这都是后话了毕竟谁知道这一年之间会不会有什么新的变故呢唯有努力注意善用 xxxx --help 来帮助自己搞清楚xxx命令的选项有哪些有什么用今天进行第一种模拟场景学习的尝试磁盘告急根分区爆满模拟场景监控报警服务器/分区使用率达到了100%网站出现500错误无法写入日志和session。你需要立即找出“罪魁祸首”并清理空间。准备工作进行一些垃圾文件的写入模拟磁盘用满的情况一、检查磁盘现在可用空间命令df -h / 查看/目录目前磁盘空间使用情况大小以我们能读懂的B、GB的单位展示二、创建目标目录模拟真实服务路径命令 sudo mkdir -p /var/log/nginx -p选项表示会自动创建不存在的父目录三、制造“罪魁祸首”大文件核心埋雷命令sudo dd if/dev/zero ofaccess.log bs1M count300生成一个300MB的假日志命名为 access.log四、制造“7天前的过期垃圾”命令# 1. 先创建一个当前时刻的临时文件用来对比touch /tmp/current_temp.tmp# 2. 创建一批修改时间为“7天前”的垃圾文件touch -d 7 days ago /tmp/old_temp_1.tmptouch -d 7 days ago /tmp/old_temp_2.tmptouch -d 8 days ago /tmp/old_temp_3.tmp# 3. 再弄点别的后缀文件增加筛选难度touch -d 7 days ago /tmp/old_temp.log五、最关键让这个大文件“被进程占用”模拟无法rm删除的情景命令安装并运行nginxsudo dnf install nginx -ysudo systemctl start nginx任务一、查看各分区挂载点及磁盘使用率人类可读格式。用到的命令df -h二、进入/目录找出大于100M的大文件显示并按照人类可读格式大小进行排序。①、cd /②、先写 find / -type f -size 100M 2/dev/null#找到根目录下大小大于100M的文件”2/dev/null“ 是直接忽略类似于“权限不够”等错误输出。③、再尝试在find命令中加入执行动作 ls -lh列出所有符合要求的文件find / -type f -size 100M -exec ls -lh {} \; 2dev/null④、最后用管道符将结果传给sort进行排序find / -type f -size 100M -exec ls -lh {} \; 2dev/null | sort -k 5,5 -hr其中sort 默认以 空格为分隔符如果输出结果中是以别的符号间隔每列数据的则可以使用-t 选项进行指定。 -k n 选项可以指定以哪一列的数据为排序标准默认从小到大进行排列。 而-hr则保证了输出的结果是人类可读的且是从大到小进行排序的。三、发现/var/log/nginx/access.log高达20G但进程正在占用该文件不能直接rm删除否则nginx无法平滑释放空间请使用正确方法清空该日志文件。用echo加上重定向符将“”输入access.log文件替换原有内容。sudo chmod 777 /var/log/nginx/access.log 让所有用户对这个文件可执行sudo echo /var/log/nginx/access.log 将输入access.log中覆盖原有内容df -h 查看覆盖后磁盘空间发现确实使用的空间减少了四、找出/tmp目录下所有7天前创建、以.tmp结尾的临时垃圾文件并删除。小插曲一在完成准备工作最后一步准备启动nginx时出现了这个报错Job for nginx.service failed because the control process exited with error code.See systemctl status nginx.service and journalctl -xeu nginx.service for details.一开始不知道是怎么了于是去提问ai。学习到了用systemctl status nginx查看状态进行排查得到以下结果定位到其中核心问题是nginx: [emerg] open() /var/log/nginx/access.log failed (13: Permission denied)经过提示后得知是可能是文件权限的问题在Nginx 主进程启动时会以某个特定的系统用户身份去读取/写入文件。通过grep ^user /etc/nginx/nginx.conf查到Nginx中配置的工作用户为nginx而通过命令ls -l /var/log/nginx/access.log查看access.log的权限-rw-r--r--. 1 root root 314572800 8月 28 14:56 /var/log/nginx/access.log可以发现nginx既不是access.log文档的所有者access文件也不对其他用户开放读写权限所以导致了nginx启动时没有权限读取access.log文件导致失败。后考虑开放文件权限使用命令sudo chmod 666 /var/log/nginx/access.log使别的用户也可以对该文件进行读写操作。但还是不行继续追问后发现nginx启动的话不仅需要读写还需要执行权限便改成了777。但没想到再次启动Nginx时还是失败查看status时还是对access.log文件的Permission denied。再追问ai后它提出可能是SELinux 的问题Red Hat家族Rocky Linux和Centos系统特有的一种增强型安全系统可能是因为它的“安全上下文“导致的问题。先通过getenforce确认SELinux是否开启再通过ls -Z /var/log/nginx/access.log查看文件的安全标签发现结果是 unconfined_u:object_r:var_log_t:s0 /var/log/nginx/access.log其中的var_log_t表明 access.log 的SELinux文件类型而nginx一般只能向文件类型为httpd_log_t的日志文件中写入这很有可能是问题所在。于是进一步修改文件类型sudo chcon httpd_log_t /var/log/nginx/access.log这次之后果然再启动nginx时也不报错了查看status时也在正常运行。小插曲二一开始用touch -d 7 days ago 创建了两个.tmp文件将他们的修改日期篡改到7天前。但在最后一步用find -mtime 7 筛选时却没有显示出这两个文件询问ai后才得知find -mtime 的筛选方法find -mtime 会对文件的修改日期进行向下取整所以实际上find -mtime 7 筛选出的是距离今天修改时间 ≥ 8天的文件find -mtime 7 才筛选的是距离今天 7~8天小于8天的文件而find -mtime -7 则筛选的是距离今天 ≤ 6天的文件。果然在使用命令find -mtime 6 后顺利地显示出了准备阶段创建的两个7天前和一个8天前创建的tmp文件。总结命令df、sort、find
返回列表