nginx报错open() "fastcgi_temp" failed (13: Permission denied)的解决办法

作者: 编程我只用CPP
时间: 2019-07-16
分类: Linux运维
评论

查看nginx日志，发现有报错信息：

2019/07/16 17:34:42 [crit] 4397#0: *349 open() "/fastcgi_temp/5/00/0000000005" failed (13: Permission denied) while reading upstream

查看对应目录的权限，发现所属用户是nobody，而实际运行nginx的是wwwuser：

root      1842  0.0  8.5 410716 332500 ?       Ss   17:10   0:01 nginx: master process /usr/local/nginx/sbin/nginx -c /etc/nginx/nginx.conf
wwwuser   4397  0.0  8.5 412288 332828 ?       S    17:33   0:00 nginx: worker process
wwwuser   4398  0.0  8.5 411776 332360 ?       S    17:33   0:00 nginx: worker process
wwwuser   4399  0.0  8.5 412800 330336 ?       S    17:33   0:00 nginx: cache manager process

因此问题原因应该是：nginx最初始时以nobody身份启动过，创建了缓存所属用户是nobody，后面改动nginx的运行用户为wwwuser，导致新用户没有权限写入缓存。

解决方案：修改对应目录下的所属用户为当前nginx启动用户。

linux环境下查看系统负载的几种方式

一、uptime和w命令

uptime命令和w命令都可以显示系统当前的负载：

ma@centos7:~$ uptime
 09:37:15 up 19 days, 20 min,  1 user,  load average: 0.00, 0.01, 0.05
ma@centos7:~$ w
 09:37:17 up 19 days, 20 min,  1 user,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
ma       pts/0    200.200.65.82    09:28    5.00s  0.01s  0.00s w

09:37:15 up 19 days, 20 min：系统启动时间
1 user：当前有一个用户在线
load average: 0.00, 0.01, 0.05：1分钟、5分钟和15分钟内的cpu平均负载

关于系统负载

系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数，如果一个进程满足以下条件则其就会位于运行队列中：

它没有在等待I/O操作的结果
它没有主动进入等待状态（也就是没有调用wait）
没有被停止（例如：等待终止）

一般来说，每个CPU内核当前活动进程数不大于3，则系统运行表现良好！当然这里说的是每个cpu内核，如果主机是四核cpu的话，那么只要uptime最后输出的一串字符数值小于12即表示系统负载不是很严重。如果达到20，那就表示当前系统负载非常严重。

二、/proc/loadavg

/proc/loadavg也能显示系统的负载信息：

ma@centos7:~$ cat /proc/loadavg 
0.01 0.02 0.05 1/199 19643

前面三个也是分别表示1分钟、5分钟以及15分钟的系统平均负载。后面的1/199表示系统当前共有199个进程，其中1个进程处于运行状态。19643表示最后一个运行的进程ID。

三、查看CPU负载情况

mpstat命令可以打印出当前系统的cpu信息，统计当前CPU的各项指标信息：

ma@centos7:~$ mpstat 
Linux 3.10.0-862.14.4.el7.x86_64 (centos7)    05/07/19    _x86_64_    (2 CPU)

10:03:33     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
10:03:33     all    0.03    0.00    0.03    0.00    0.00    0.07    0.09    0.00   99.78

%user：在internal时间段里，用户态的CPU时间(%)，不包含nice值为负进程。(usr/total)*100
%nice：在internal时间段里，nice值为负进程的CPU时间(%)。(nice/total)*100
%sys：在internal时间段里，内核时间(%)。(system/total)*100
%iowait ：在internal时间段里，硬盘IO等待时间(%)。(iowait/total)*100
%irq：在internal时间段里，硬中断时间(%)。(irq/total)*100
%soft：在internal时间段里，软中断时间(%)。(softirq/total)*100

常用参数

-P CPU：打印指定CPU的信息，默认只打印所有CPU汇总后的统计数据，加上-P ALL会把每个CPU的统计信息都打印出来。
interval times：每隔interval统计一次信息，共统计times次。

例如，每1秒打印一次cpu信息，共打印2次：

最后会针对这三次生成一次统计信息。

四、查看内存

free命令可以查看当前的内存：

maqian@os:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          16285        5096       10964          17         223       11057
Swap:         29663           0       29663

Mem表示的是系统的物理内存，Swap是虚拟内存。

五、使用top查看CPU和内存占用

top命令可以查看当前系统下所有进程的CPU和内存占用情况：

输入命令后会进入交互式界面，在交互式页面输入P可以对CPU占用排序，输入M对内存占用排序。

一、问题描述

某天，在QQ空间看到大学同学发了一个求助帖：

求助安装一个ffmpeg软件（(linux平台下开源的音视频转码工具），本着助人为乐的想法准备提供一下帮助，了解之后才发现她想做的根本不是安装ffmpeg，而是已经装好了发现命令执行太卡，以为自己装错了，想找个熟人重装一下。再次深入了解才发现最终的问题是这样的：她们用的腾讯云学生机（1C1G配置），平常在上面用ffmpeg做音视频转码的实验，一个10M左右的视频转码需要十几分钟，觉得时间太长了，并且看到的日志显示他们转码并没有消耗CPU资源。

最后排查下来发现系统是被黑客入侵了，排查相当顺利（比起我们公司设备的排查简直容易一百倍），记录下排查过程。

二、排查过程

了解具体问题之后发现了两个不寻常的地方：

10M的视频转码要10分钟以上-----单核CPU应该也不至于此。
她们看到的日志显示没有占用CPU资源-----没有GPU，视频转码不耗CPU不太可能。

首先登陆上设备，看CPU占用：发现设备上以ftpuser运行了一个bash64的进程，常年占用CPU在97%以上。

第一眼看上去就很奇怪，为什么ftpuser会运行bash64？而且一般的bash也不叫bash64，为什么CPU占用会这么高？一种不妙的感觉顿时涌上心头，当时感觉就可能是被黑了。

尝试关闭进程，果然，根本关不掉，关了又起来。ps查看文件所在位置之后删除也不行，删除后还会自动创建，进程也还是会起来。

再仔细一看，发现进程执行的程序是放在ftpuser主目录下的一个隐藏文件夹下，同时还有个配置参数，cat这个文件竟然是一串ssh密钥。这明显就是一个挖矿进程了。

。。。于是乎，排查结束！

三、解决方案

结论：

系统被黑客入侵，植入了挖矿程序，一直占用CPU导致其他程序无法得到CPU资源，出现了ffmpeg转码卡慢的问题。

解决方案：

因为工作太忙（当时已经是晚上快十点了还在公司加班。。。）没有深入分析下去，直接建议重装系统了。

事后发现：

腾讯云早已发送告警短信到她手机，她熟视无睹：

2019年7月

linux添加永久静态路由

nginx报错open() "fastcgi_temp" failed (13: Permission denied)的解决办法