ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | check_file - одна ошибка сервиса валит остальные проверки | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Mike Lykov <combr> |
| Component: | monit | Assignee: | Michael Shigorin <mike> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | evg, mike |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
Спасибо; в идеале бы сразу в апстрим отрепортить (я сейчас разгребаюсь после командировки): https://savannah.nongnu.org/bugs/?func=additem&group=monit ну мало ли. Вдруг это локальное? если у кого воспроизводится.. Неприятный результат-то этого (у меня) тот, что из-за if timestamp > 65 minutes then restart (пытался задать проверку "а не повисло ли все тут?") все это внезапно перезагружается, если поменялись права или gid файла.. Да, при такой конфигурации это неправильно. кстати вероятно, что вот это: http://lists.altlinux.org/pipermail/sysadmins/2008-April/025692.html является подтверждением той же проблемы. "current permission is 0" похоже на "current gid is 0" .. т.е. например поменялась checksum, а ругается заодно и на permission (обнуленный). Спасибо. Просьба проверить на 5.3, если воспроизводится -- буду дёргать апстрим в рассылке (со ссылкой на багрепорт). ping ping (сегодня грозились 5.4 выпустить) в другом месте, на другом сервере, с другой версией попробовал воспроизвести monit-5.17.1-alt3 после chmod 644 /var/log/syslog/messages с сообщением Dec 23 14:32:00 www monit[23501]: 'syslog_file' permission test failed for /var/log/syslog/messages [current permission 0644] переходит в состояние File 'syslog_file' status Not monitored все, больше никаких нижеописанных эффектов (В ответ на комментарий №10) > после chmod 644 /var/log/syslog/messages > переходит в состояние > File 'syslog_file' > status Not monitored Это как раз ожидаемо. > все, больше никаких нижеописанных эффектов Тогда WORKSFORME? (В ответ на комментарий №11) > > все, больше никаких нижеописанных эффектов > Тогда WORKSFORME? не помню, какие там статусы у resolved, но "worksforme" означает "не подтверждается, не было и нет". тут не тот случай, скорее через 5,5 лет всё же исправили. (В ответ на комментарий №12) > > > все, больше никаких нижеописанных эффектов > > Тогда WORKSFORME? > не помню, какие там статусы у resolved, но "worksforme" означает > "не подтверждается, не было и нет". Это скорее notabug уже :] > тут не тот случай, скорее через 5,5 лет всё же исправили. Я воспринимаю в подобных случаях worksforme как осторожное fixed, когда воспроизвести баг у причастных не получается, но твёрдой уверенности в виде конкретного коммита/патча/версии по конкретному багу нет. --- * WORKSFORME — майнтейнер не может воспроизвести ошибку и просит у пользователя дополнительную информацию. --- http://www.altlinux.org/BugTracking/BugzillaMiniHowto Впрочем, не настаиваю, пусть будет fixed. |
Суть такая. есть последний на данный момент rpm -q monit monit-5.2.5-alt0.M51.1 есть стандартный тест (из examples): check file syslog_file with path /var/log/syslog/messages if timestamp > 65 minutes then restart if failed permission 640 then unmonitor if failed uid root then unmonitor if failed gid adm then unmonitor тут группа из 4-х тестов. В ситуации, когда эти условия удовлетворяются - все работает успешно (долго): File 'syslog_file' status accessible monitoring status monitored permission 640 uid 0 gid 4 timestamp Tue May 17 13:40:36 2011 size 75091 B data collected Tue May 17 13:40:42 2011 # stat /var/log/syslog/messages File: `/var/log/syslog/messages' Size: 83486 Blocks: 166 IO Block: 1024 regular file Device: 302h/770d Inode: 18 Links: 1 Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 4/ adm) Access: 2011-05-17 12:41:09.000000000 +0400 Modify: 2011-05-17 14:14:01.000000000 +0400 Change: 2011-05-17 14:14:27.000000000 +0400 работает, работает... меняю вручную права на файл: chmod 644 /var/log/syslog/messages # stat /var/log/syslog/messages File: `/var/log/syslog/messages' Size: 82654 Blocks: 164 IO Block: 1024 regular file Device: 302h/770d Inode: 18 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 4/ adm) Access: 2011-05-17 12:41:09.000000000 +0400 Modify: 2011-05-17 14:10:51.000000000 +0400 Change: 2011-05-17 14:10:51.000000000 +0400 По идее, один тест должен провалиться. А остальные в этой группе? File 'syslog_file' status GID failed monitoring status monitored permission 0 uid 0 gid 0 timestamp Thu Jan 1 03:00:00 1970 size 0 B data collected Tue May 17 13:45:27 2011 В логе: May 17 14:18:46 vep01 monit[2154]: 'syslog_file' permission test failed for /var/log/syslog/messages -- current permission is 0644 May 17 14:18:46 vep01 monit[2154]: 'syslog_file' gid test failed for /var/log/syslog/messages -- current gid is 0 May 17 14:18:46 vep01 monit[2154]: 'syslog_file' timestamp test failed for /var/log/syslog/messages May 17 14:18:46 vep01 monit[2154]: 'syslog_file' trying to restart Т.е. хотя я поменял всего лишь права - проваливаться стали _все_ тесты. Размер файла стал 0, дата стала 0 (unixtime), uid/gid стали 0. у меня это повторяемо - если сделать chmod 640 /var/log/syslog/messages в логе будет May 17 14:15:36 vep01 monit[2154]: 'syslog_file' gid succeeded May 17 14:15:36 vep01 monit[2154]: 'syslog_file' timestamp succeeded и все заработает. 644 - и опять все тесты провалятся. Что это за странное поведение? и даже больше: меняю gid на apache. Остальное в порядке: # stat /var/log/syslog/messages File: `/var/log/syslog/messages' Size: 87698 Blocks: 174 IO Block: 1024 regular file Device: 302h/770d Inode: 18 Links: 1 Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 96/ apache) Access: 2011-05-17 14:37:29.000000000 +0400 Modify: 2011-05-17 14:37:49.000000000 +0400 Change: 2011-05-17 14:37:49.000000000 +0400 ситуация повторяется: File 'syslog_file' status Timestamp failed monitoring status monitored permission 0 uid 0 gid 0 timestamp Thu Jan 1 03:00:00 1970 size 0 B data collected Tue May 17 14:37:49 2011 опять все по 0, только вместо ошибки "gid failed" (что правда) - получаю "Timestamp failed" ...