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裏最好顯示指定文件的權限.