Sometimes I get the following email from stat1005, sent to root@ due to logrotate failures:
/etc/cron.daily/logrotate: error: error setting owner of /srv/reportupdater/log/limn-language-data-interlanguage.log-20180401.gz to uid 116 and gid 122: Operation not permitted run-parts: /etc/cron.daily/logrotate exited with return code 1
In this case:
elukey@stat1005:~$ ls -l /srv/reportupdater/log/limn-language-data-interlanguage.log-20180401.gz -rw------- 1 hdfs wikidev 0 Apr 9 06:25 /srv/reportupdater/log/limn-language-data-interlanguage.log-20180401.gz
Complete view:
elukey@stat1005:~$ ls -l /srv/reportupdater/log/limn-language-data-interlanguage.log* -rw------- 1 hdfs wikidev 48976 Apr 10 06:00 /srv/reportupdater/log/limn-language-data-interlanguage.log -rw-r--r-- 1 hdfs hdfs 348610 Apr 1 06:00 /srv/reportupdater/log/limn-language-data-interlanguage.log-20180401 -rw------- 1 hdfs wikidev 0 Apr 9 06:25 /srv/reportupdater/log/limn-language-data-interlanguage.log-20180401.gz
Logrotate settings:
elukey@stat1005:~$ cat /etc/logrotate.d/reportupdater
# This file is managed by Puppet.
/srv/reportupdater/log/*.log {
notifempty
maxage 30
rotate 2
dateext
compress
delaycompress
missingok
su hdfs wikidev
}In theory, we have the following on stat1005:
elukey@stat1005:~$ cat /etc/profile.d/umask-wikidev.sh # !this file is managed by puppet! # set umask to 0002 for wikidev users # to prevent broken repos per T79400 if groups | grep -w -q wikidev; then umask 0002 else umask 0022 fi
So if a user is in wikidev it inherits the 0002 umask (so user/group allowed to write, not only user). The hdfs user is not in this group, so the umask is not set as we wished.