docker container logrotate不生效問題

過程

給syslog docker增長了日誌分析腳本. 腳本會使用最短編輯距離算法, 歸集錯誤日誌, 發送到測試環境報警羣. 該腳本依賴logrotate.次日一早沒有看到預期的錯誤歸集報警. 發現logrotate不工做了.

xxxxxxxx@xxxxxxxx:/srv/log/p10057_syslog/rsyslog$ cat analyze_error_log.log 
('log_path_not_exist', '/srv/log/rsyslog/ejoy_errors/error.log.xxxxxxx')

增長日誌分析腳本作了2個事情:

• 用crontab調用分析腳本.
• build了一個新的syslog docker image, 增長了腳本依賴的幾個python庫.

猜想:
logrotate依賴crontab, crontab的配置覆蓋了logrotate的按期執行
回滾docker image 版本, 以前並無crontab任務.
事實上開發時已經檢查過這一項, 之因此懷疑crontab, 是由於確實沒有可疑改動了.

ubuntu# crontab -l
no crontab for root

最後發現是logrotate.conf文件權限問題:

root@xxxxxxx:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf 
Ignoring /etc/logrotate.conf because of bad file mode.
Handling 0 logs
root@xxxxxxxx:/etc# ls -l /etc/logrotate.conf 
-rw-rw-r-- 1 root root 351 Sep 29 03:47 /etc/logrotate.conf
root@xxxxxx:/etc# chmod 644 /etc/logrotate.conf 
root@xxxxxx:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf 
reading config file /etc/logrotate.conf
Handling 1 logs
rotating pattern: /srv/log/rsyslog/*/*.log  4096 bytes (14 rotations)
empty log files are rotated, old logs are removed
considering log /srv/log/rsyslog/admin/access.log
  log does not need rotating
considering log /srv/log/rsyslog/admin/admin.log
....

那就很詭異了, 爲何logrotate.conf的權限會發生變化呢? 在此以前, 我不知道有logrotate.conf文件, 更不用說修改了.
syslog/Dockerfile 裏有這樣一行, 鏡像內logrotate.conf文件的權限由build docker image機器上syslog/logrotate.conf的權限決定:
COPY logrotate.conf /etc/logrotate.conf
發佈機器上 logrotate.conf 的 filemode 是 644, 而我是 664. 是我不當心修改了 logrotate.conf 的 filemode 嗎? 而filemode爲false致使我忽略了filemode的修改?

git config core.filemode false

將core.filemode 設爲true也看不到diff, 通過一番嘗試, 發現git的一個冷知識:

git 只記錄文件的 executable bit

https://medium.com/@tahteche/...
即, 對git來講, filemode只有755 (user executable) 和644 (user not executable).

好吧, 是我無心間修改了 logrotate.conf 的 filemode嗎? 個人 logrotate.conf 確實是 664, 打包機上確實是 644. 鐵證如山.
從新 checkout battleship, 新checkout的 logrotate.conf 是 664. 又引出一個新的問題.

umask 和 USERGROUPS_ENAB

https://superuser.com/questio...

嘗試後發現.
不一樣在於, 個人umask是002, 而打包機是0022.
個人 user_name 等於 group_name, 而打包機 user_name 和 group_name 不同.

~ » touch aa
~ » ls -l aa
-rw-rw-r-- 1 enjolras enjolras 0 Sep 29 19:09 aa
~ » umask
002
platformdeploy@DEPLOY-192-168-0-116:~$ touch a
platformdeploy@DEPLOY-192-168-0-116:~$ ls -l a
-rw-r--r-- 1 platformdeploy platform 0 Sep 29 19:56 a
platformdeploy@DEPLOY-192-168-0-116:~$ umask
0022
less /etc/login.defs
Enable setting of the umask group bits to be the same as owner bits
(examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
the same as gid, and username is the same as the primary group name.
If set to yes, userdel will remove the user´s group if it contains no
more members, and useradd will create by default a group with the name
of the user.
USERGROUPS_ENAB yes

結論

不一樣的環境下, checkout出來的文件權限不同. DockerFile裏最好顯示指定文件的權限.