Ruby не удается открыть файл 644 только для чтения

$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

Это важная строка скрипта (/etc/munin/plugins/nginx_status_codes.rb:31):

File.open("/var/log/nginx/access.log", File::RDONLY).readlines.each do |line|

Мой журнал доступа имеет глобальные права на чтение:

$ ls -lha /var/log/nginx/access.log
-rw-r--r-- 1 www-data adm 49M May  1 15:56 /var/log/nginx/access.log

Скрипт работает, если я запускаю из терминала как обычный пользователь...

$ /etc/munin/plugins/nginx_status_codes > /dev/null && echo $?
0

... но не работает, если запускается Munin (который запускается от имени root):

2012/05/01-15:54:05 [3988]  /etc/munin/plugins/nginx_status_codes:31:in `initialize': Permission denied - /var/log/nginx/access.log (Errno::EACCES)
2012/05/01-15:54:05 [3988]      from /etc/munin/plugins/nginx_status_codes:31:in `open'
2012/05/01-15:54:05 [3988]      from /etc/munin/plugins/nginx_status_codes:31

Это также не работает, если я устанавливаю права доступа к файлу на 777 или что-то еще. Я думаю, что Руби просто глуп и сообщает о неправильном исключении (Errno:EACCES) и маскирует реальную проблему. Но что бы это было?

ОБНОВЛЕНИЕ: Попытался «исправить» это, установив сценарий, принадлежащий root:root и даже с установленными битами sid/gid, ему удается сбой с отказом в разрешении.


person hcalves    schedule 01.05.2012    source источник
comment
Я не знаком с Муниным. Он действительно работает как root? Разве он не переключается на другой идентификатор пользователя после инициализации? Если да, то имеет ли этот идентификатор пользователя доступ к каталогам /var, /var/log и /var/log/nginx?   -  person theglauber    schedule 01.05.2012
comment
У меня есть Munin, работающий и как пользователь, и как корень группы согласно munin.cfg. Но вы можете быть правы, хотя может случиться так, что при запуске скрипта он отбрасывает пользователя root. Что мне кажется странным, так это то, что я могу запускать скрипт как обычный пользователь, не сталкиваясь с проблемами доступа.   -  person hcalves    schedule 01.05.2012


Ответы (1)


Неважно. Проблема заключалась в том, что существовала ротация журналов, которая время от времени меняла права доступа к файлу журнала:

$ cat /etc/logrotate.d/nginx 
/var/log/nginx/*.log {
    daily
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi; \
    endscript
    postrotate
        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
    endscript
}
person hcalves    schedule 01.05.2012
comment
Чтобы сигнализировать nginx о повторном открытии файлов журнала: wiki.nginx.org/CommandLine#Stopping_or_Restarting_Nginx - person hcalves; 02.05.2012