13: Permission denied
前段時(shí)間把程序員的wordpress升級到3.5.1，本身如果沒有特別的插件，在后臺(tái)更新就能完成。
更新完成后在后臺(tái)發(fā)布文章，編輯器不能點(diǎn)擊可視化標(biāo)簽，只能顯示html標(biāo)簽，看了下js控制臺(tái)提示ReferenceError: tinyMCE is not defined 3.5。
直覺以為升級哪里有問題，簡單粗暴的重裝了，可是還是不行，這時(shí)候就覺得可能是nginx哪里配置的問題了。
查看了一下日志文件，發(fā)現(xiàn)有下面的錯(cuò)誤提示：
|
1
|
2013/03/13 01:22:17 [crit] 3331#0: *10 open() "/usr/local/lnmp/nginx/fastcgi_temp/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: 124.42.13.230, server: 264.cn, request: "GET /wp-admin/load-scripts.php?c=0&load%5B%5D=jquery,utils,plupload,plupload-html5,plupload-flash,plupload-silverlight,plupload-html4,json2&ver=3.5.1 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "264.cn", referrer: "http://www.nginx.cn/wp-admin/post-new.php" |
很明瀏覽器只加載了部分頁面，原因是Permission denied。
首先確認(rèn)工作進(jìn)程(worker process)的用戶:
檢查配置文件nginx.conf的user指令
|
1
|
user www-data; |
后者執(zhí)行命令
|
1
|
#ps aux | grep "nginx: worker process" | awk '{print $1}' |
|
1
|
www-data |
都可以得到nginx工作進(jìn)程的運(yùn)行用戶
檢查nginx的proxy_temp目錄的所有者，
|
1
|
drwx------ 2 root root 4096 Mar 3 03:28 proxy_temp |
可以看到proxy_temp的所有者不是www-data，修改目錄所有者為www-data即可。
|
1
|
chown -R www-data:www-data proxy_temp |
通過以上的步驟，wordpress就可以正常的顯示，不會(huì)出現(xiàn)后臺(tái)的js錯(cuò)誤了。
分析下failed (13: Permission denied) while reading upstream問題的原因
首先看一下nginx 反向代理參數(shù)說明
- proxy_connect_timeout 600; #nginx跟后端服務(wù)器連接超時(shí)時(shí)間(代理連接超時(shí))
- proxy_read_timeout 600; #連接成功后，后端服務(wù)器響應(yīng)時(shí)間(代理接收超時(shí))
- proxy_send_timeout 600; #后端服務(wù)器數(shù)據(jù)回傳時(shí)間(代理發(fā)送超時(shí))
- proxy_buffer_size 32k; #設(shè)置代理服務(wù)器（nginx）保存用戶頭信息的緩沖區(qū)大小
- proxy_buffers 4 32k; #proxy_buffers緩沖區(qū)，網(wǎng)頁平均在32k以下的話，這樣設(shè)置
- proxy_busy_buffers_size 64k; #高負(fù)荷下緩沖大小（proxy_buffers*2）
- proxy_temp_file_write_size 64k; #設(shè)定緩存文件夾大小，大于這個(gè)值，將從upstream服務(wù)器傳
問題就出在proxy_temp_file_write_size上，當(dāng)你的文件超過該參數(shù)設(shè)置的大小時(shí)，nginx會(huì)先將文件寫入臨時(shí)目錄(缺省為nginx安裝目下/proxy_temp目錄),
如果nginx對prxoy_temp沒有權(quán)限就會(huì)寫不進(jìn)去，結(jié)果就是只顯示部分頁面。
我遇到這個(gè)案例用工具查看了一下，post-new.php這個(gè)頁面大小事94，超過了64k就要符合我們上面的分析。
File not found 錯(cuò)誤
使用php-fpm解析PHP，"No input file specified"，"File not found"是令nginx新手頭疼的常見錯(cuò)誤，原因是php-fpm進(jìn)程找不到SCRIPT_FILENAME配置的要執(zhí)行的.php文件，php-fpm返回給nginx的默認(rèn)404錯(cuò)誤提示。
比如我的網(wǎng)站doucument_root下沒有test.php，訪問這個(gè)文件時(shí)通過抓包可以看到返回的內(nèi)容。
|
1
2
3
4
5
6
7
8
9
10
|
HTTP/1.1 404 Not FoundDate: Fri, 21 Dec 2012 08:15:28 GMTContent-Type: text/htmlProxy-Connection: closeServer: nginx/1.2.5X-Powered-By: PHP/5.4.7Via: 1.1 c3300 (NetCache NetApp/6.0.7)Content-Length: 16File not found. |
很多人不想用戶直接看到這個(gè)默認(rèn)的404錯(cuò)誤信息，想自定義404錯(cuò)誤.
給出解決辦法前我們來先分析下如何避免出現(xiàn)這類404錯(cuò)誤，然后再說真的遇到這種情況(比如用戶輸入一個(gè)錯(cuò)誤不存在的路徑)時(shí)該怎么辦，才能顯示自定義的404錯(cuò)誤頁。
一、錯(cuò)誤的路徑被發(fā)送到php-fpm進(jìn)程
出現(xiàn)這類錯(cuò)誤，十個(gè)有九個(gè)是后端fastcgi進(jìn)程收到錯(cuò)誤路徑(SCRIPT_FILENAME)，而后端fastcgi收到錯(cuò)誤路徑的原因大都是配置錯(cuò)誤。
常見的nginx.conf的配置如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
server { listen [::]:80; server_name example.com www.example.com; access_log /var/www/logs/example.com.access.log; location / { root /var/www/example.com; index index.html index.htm index.pl; } location /images { autoindex on; } location ~ .php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/example.com$fastcgi_script_name; include fastcgi_params; }} |
這個(gè)配置中有很多不合理的地方，其中一個(gè)明顯的問題就是root指令被放到了location / 塊。如果root指令被定義在location塊中那么該root指令只能對其所在的location生效。其它locaiont中沒有root指令，像location /images塊不會(huì)匹配任何請求，需要在每個(gè)請求中重復(fù)配置root指令來解決這個(gè)問題。因此我們需要把root指令放在server塊，這樣各個(gè)location就會(huì)繼承父server塊定義的$document_root，如果某個(gè)location需要定義一個(gè)不同的$document_root，則可以在location單獨(dú)定義一個(gè)root指令。
另一個(gè)問題就是fastCGI參數(shù)SCRIPT_FILENAME 是寫死的。如果修改了root指令的值或者移動(dòng)文件到別的目錄，php-fpm會(huì)返回“No input file specified”錯(cuò)誤，因?yàn)镾CRIPT_FILENAME在配置中是寫死的并沒有隨著$doucument_root變化而變化，我們可以修改SCRIPT_FILENAME配置如下：
|
1
|
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; |
所以我們不能忘記在server塊中配置root指令，不然$document_root的值為空，只會(huì)傳$fastcgi_script_name到php-fpm，這樣就會(huì)導(dǎo)致“No input file specified”錯(cuò)誤。
二、請求的文件真的不存在
當(dāng)nginx收到一個(gè)不在的.php文件的請求時(shí),因?yàn)閚ginx只會(huì)檢查$uri是否是.php結(jié)尾，不會(huì)對文件是否存在進(jìn)行判斷，.php結(jié)尾的請求nginx會(huì)直接發(fā)給php-fpm處理。php-fpm處理時(shí)找不到文件就會(huì)返回“No input file specified”帶著“404 Not Found”頭。
解決辦法
我們在nginx攔截不存在的文件，請求并返回自定義404錯(cuò)誤
使用 try_files 捕捉不存在的urls并返回錯(cuò)誤。
|
1
2
3
4
5
6
7
8
|
location ~ .php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME .... ................................... ...................................} |
上面的配置會(huì)檢查.php文件是否存在，如果不存在，會(huì)返回404頁面。
