Владелец/группа каталога /var/empty root:root, права 555 fetchmail запускаю как демон, service fetchmail start в логе вижу: [root@mserver mail]# cat /var/log/fetchmail/fetchmail.log /var/empty/.fetchmail.pid: Отказано в доступе fetchmail: lock creation failed. Права на каталог /var/empty изменить можно, и тогда fetchmail работает, но перестает работать sshd, с криком: Dec 8 09:33:49 mserver sshd[19641]: Unable to check blacklist for host key 0c:a8:13:be:c0:be:44:c1:58:2a:9d:b5:61:b9:5a:4e Dec 8 09:33:49 mserver sshd[19641]: fatal: /var/empty must be owned by root and not group or world-writable. Dec 8 09:33:56 mserver sshd: Checking sshd configuration: failed Вот конфиг fetchmai'а: [root@mserver var]# cat /etc/fetchmailrc # Configuration created Sat May 22 13:33:07 2004 by fetchmailconf set logfile "/var/log/fetchmail/fetchmail.log" set postmaster "postmaster@domain" set no bouncemail set no spambounce set properties "" set daemon 600 poll address.domain with proto POP3 localdomains тут перечислены локальные домены no envelope #envelope 'Delivered-To:' no dns user 'username' there with password 'password' is * here fetchall antispam 550 Установлены пакеты: fetchmail-6.3.8-alt6.1 fetchmail-daemon-6.3.8-alt6.1 Единственный выход, это изменить права, потом запустить fetchmail, после того как он создаст свой pid файл изменить пара обратно, что бы мог работать sshd :(
Юрий, я не поддерживаю fetchmail и очень давно его не использую. Вы можете это оспорить одним-единственным образом: помочь, а не перевешивать с того, кто добрался и починил ещё более важное, на того, кто вряд ли за полгода доберётся. А если сильно мешает, патчи действительно приветствуются. Пока же предлагаю засунуть под cron. 2 ender: Дим, это не к тому, чтоб всё бросить и подскакивать, но по факту в 4.1/branch ещё и дырка в fetchmail есть. Поэтому стоит не спеша поправить в сизифе и сделать бэкпорт. Ну и постарайся не нагребать всего-всего, чтоб оно не напрягало.
была у меня мысль его забрать даже, так что если терпения дождаться хватит - починим. если нет, то как показывает опыт, патчи дейстиетельно ускоряют починку :) > Ну и постарайся не нагребать всего-всего, чтоб оно не напрягало. беру лишь интересное, знакомое, либо прям на грани вылета из сизифа :)
ахааа, при установке пакета добавляется пользователь: %_sbindir/useradd -r -n -M -g %name -d /var/empty -s /dev/null %name &>/dev/null ||: судя по -d его домашний каталог - /var/empty. либо его сменить на какой-нить /var/run/fetchmail, либо fetchmail патчить, чтобы в daemon mode нормальный pidfile использовал. где-то я эту проблему у fetchmail'а что-то видел...
Спасибо большое, изменил ему домашнюю директорию на /var/run/fetchmail и все стало на свои места.
пожалуйста :) баг пока рано закрывать, надо в пакете изменения внести, чтобы при обновлении/установке редактировал.
разобрался, откуда этот "косяк". lock.c: если не указан pidfile напрямую, то pidfile генерируется: 1. для рута: PID_DIR + fetchcmail.pid 2. для "простого" пользователя: FETCHMAIL_HOME + fetchmail.pid и если FETCHMAIL_HOME совпадает с домашним каталогом пользователя, то HOME + .fetchmail.pid а fethcmail у нас работает от простого пользователя, FETCHMAIL_HOME устанавливается только через FETCHMAILHOME, иначе равен HOMEDIR. вот и получаем, что pidfile сохраняется в /var/empty/.fetchmail.pid, где /var/empty - домашний каталог fetchmail'а. в fetchmail.init pidfile для глобавльных настроек не задается, видимо в расчете, что fetchmail сам соориентируется. так и есть, для рута - там генерится /var/run/fetchmail.pid. но у нас-то не рут, а системный юзверь. посему, запишу-ка я в init скрипте параметр --pidfile для для глобальных настроек и сменю homedir на /var/lib/fetchmail. homedir будет конечно пустым, на на всякий пусть будет :)
сборку отправил как в сизиф, так и в M41. homedir оставил /var/run/fetchmail, в качестве pidfile указал /var/run/fetchmail/fetchmail.pid. указал как для start-stop-daemon, так и для fetchmail. service stop/start проверил - работает. как до бранча доберется - можно закрывать.
всё, добрался.
