用過Laravel的小夥伴一開始安裝完框架後可能都遇到過daily 日誌文件寫入失敗的問題,接下來我們就來詳細說下日誌文件寫入失敗的原因以及對應的解決方案。
在講這個問題之前可能需要簡單介紹下Linux系統下的文件的Ownership和Permission。
-
Ownership
- User
User是文件的所有者,默認情況下,用戶創建了一個文件,該文件的所有者就是該用戶。
- Group
一個用戶組能包含多個用戶,所有屬於這個組的用戶都有相同的權限來訪問文件。假設你有一個項目,很多用戶都需要訪問這個項目文件的權限,你不需要手動賦予這些用戶所有權限,你只需要把這些用戶加到一個組裏面,賦予這些組有訪問文件的權限,這樣一來就僅僅只有組裏面的成員能對文件進行讀寫操作。
- Other
任何其他的用戶都能訪問文件,因此,給Other用戶賦予權限,相當於所有用戶都擁有這個權限。
- User
-
Permission
在 UNIX/Linux 系統中每一個文件和目錄都有3中權限,以下就是對三個所有者的討論。
- Read:這個權限賦予你打開和讀取文件的權限。擁有目錄的讀權限,你能列出其內容。
- Write:擁有了讀權限,你能修改文件的內容。擁有了目錄的寫權限,你能添加、移除以及重命名該目錄下的文件。考慮一種場景,當你擁有文件的寫權限,但是沒有文件存儲目錄的寫權限,你還是能修改文件的內容,但不能重命名、移動以及移除目錄下的文件。
- Execute:在Windows系統中,一個可執行的程序通常都有.exe後綴,你能很方便的運行它。在 UNIX/Linux 中,除非被賦予可執行權限,否則你將不能運行該程序。如果未授權可執行權限,你讓然可以看並修改程序代碼(被授予讀和寫權限),但是無法運行它。
<div style="text-align:center;font-size:12px">linux下文件信息的顯示截圖</div>
<div style="text-align:center;font-size:12px">linux下目錄的信息顯示截圖</div>
以上的截圖顯示了一個文件和文件夾的信息,我們可以看到:
-
r
代表可讀,w
代表可寫,x
代表可執行。 - 第一位文件顯示
-
,文件顯示d
。 - 上面第一張圖片,
rw-rw-r-—
中。第一組rw-
表示文件的所有者對文件有可讀、可寫、不可執行的權限。第二組rw-
表示文件所屬的組內用戶對該文件有可讀、可寫、不可執行的權限。第三組r-—
表示其他任何用戶對該文件有可讀、不可寫、不可執行的權限。 -
rw-rw-r--
用二進制表示爲664
,每一位如有權限則爲1
,否則爲0
,第一個三位rw-
用二進制表示爲110
轉化爲十進制就是6
,後面兩組依次類推,最後得到664
。 - 上面第一張圖片的
dior www-data
表示該文件的所有者是dior
用戶,文件屬於www-data
組。
我們知道很多應用系統中的日誌是寫文件的,且是以日期來命名文件的。所以第一次創建日誌的用戶就顯得尤爲重要,如果文件創建的 Onwer
和 Group
不對,其他的用戶觸發寫入日誌文件就會失敗。
接下來我們討論下有多少種不同的用戶可能創建日誌文件:
-
Crontab
中執行的定時任務,跟創建Crontab
的用戶有關,此時創建的文件Owner
和Group
值分別是該用戶以及默認的Group
。 - 一些常駐的後臺進程,比如Laravel中的
queue work
,此時創建的日誌文件Owner
和Group
值分別是執行該進程的用戶以及所屬的默認Group
。 - 正常用戶訪問網站產生的日誌文件,此時創建的日誌文件的
Owner
和Group
都是www-data
,www-data
用戶是web服務器默認的用戶。
由以上的分析,我們大概已經找到了解決問題的方法。
- 執行用戶創建日誌文件的權限爲
664
比較恰當,這就需要當前用戶的umask爲0002
。 - 當前執行用戶的默認
Group
應該設置爲www-data
。
下面就說下我的具體解決方案:
指定www-data用戶執行crontab:
sudo crontab -u www-data -e
Laravel中修改創建日誌文件的權限:
編輯 confog/logging.php
文件
添加 'permission' => 0664
'daily' => [
'driver' => 'daily',
'path' => storage_path('logs/laravel.log'),
'level' => 'debug',
'days' => 14,
'permission' => 0664,
],
你有什麼更好的方法麼?歡迎留言!