From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 26 Nov 2002 23:29:41 +0300 From: Sergey Kuznetsov To: sisyphus@altlinux.ru Subject: Re: [sisyphus] Fetchmail trouble - =?KOI8-R?B?0sHaws/SINDPzMXUzw==?= =?KOI8-R?B?1w==?= Message-Id: <20021126232941.2b695067.yozhik@atom.ru> In-Reply-To: References: <20021124105452.626b8b3b.yozhik@atom.ru> X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i586-alt-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Sender: sisyphus-admin@altlinux.ru Errors-To: sisyphus-admin@altlinux.ru X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: sisyphus@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: On Sun, 24 Nov 2002 05:41:46 -0600 (CST) Igor Moskalev wrote: > On Sun, 24 Nov 2002, Sergey Kuznetsov wrote: > > > Здравствуйте! > > > > Напомню, в чем состояла проблема. В ходе обновлений из > > Сизифа > > вдруг обнаружилось, что fetchmail 5.9.12 (как в обычном > > режиме, > > так и демон) перестал принимать почту. В ответ на команду > > service > > fetchmail status следовал загадочный ответ: fetchmail > > dead but > > subsys locked, смысл которого так и не удалось > > расшифровать. > > Обновление fetchmail до 6.1.2-alt2 также не помогло. > > Сегодня > > попробовал настроить fetchmail на собственный почтовый > > ящик от > > имени другого юзера и, к большому удивлению, все > > заработало. > > После пристального копания в /home, бессмысленного > > редактирования > > .fetchmailrc и т.п., обратил наконец внимание на > > о-о-очень > > скромный файлик .fetchmail.pid размером 0 b. И после его > > сноса > > произошло чудо: запущенный в который раз fetchmail начал > > исправно > > таскать почту. Таким образом, проблема решилась, но, в > > порядке > > разбора полетов, хочется спросить у знатоков: что ЭТО > > было, и > > откуда ОНО могло взяться? > > > > С уважением, > > Сергей > > > > Рискну предположить, что при обновлении самого fetchmail, не > был удален тот самый ~/.fetchmail.pid (т-н. loc file). Вы > проведите такой эксперимент: При работающем fetchmail > > ls -al ~/.fetchmail.pid > > Затем service fetchmail stop и еще раз предыдущую команду -- > этого файла не должно быть. Видимо при переустановке fetchmail > он был остановлен"ненормально" и поэтому этот файл не удалился. > А когда запустился свежеустановленный вариант, он проверил и > увидел этот самый лок файл, и отказался запускаться (как и > должно быть, чтобы предотвратить запуск нескольких, никак между > собой несинхронизированных копий). В таких случаях лучше > запускать программу вручную из командной строки и смотреть на > вывод. Или логи глядеть... > > P.S. Одного мне не понять -- почему размер файла нулевой? По > идее там должен быть записан pid процесса fetchmail ... Поспешил я порадоваться. Этот файлик продолжает возрождаться после каждого рестарта. Причем не нулевой: [yozhik@localhost yozhik]$ cat .fetchmail.pid 2101 600 Мочу, далее все OK. До следующего рестарта. Причем у тестового юзера тоже самое (его fetchmailrc создавался _заново_ из под этого самого юзера). Может я что-то глобально не так делаю? Сейчас fetchmail запускается как сервис в init 5, все fetchmailrc лежат в /home у соответствующих юзеров. Может надо создать fetchmailrc от имени root (сервисы ведь, вроде, от рута запускаются)? И еще одна мысль в голову пришла: у меня в fetchmailrc прописано set daemon 600. Не может ли при этом происходить запрещенный запуск 2-го процесса? В man fetchmail я что-то ответа не нашел (может искал плохо?). С уважением, Сергей