ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | snmpd перестал читать сведения из /proc после апгрейда на kernel-image-std-up-2.4.22-alt16 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Andrei Bulava <abulava> | ||||
| Component: | net-snmp | Assignee: | Kostya Timoshenko <kt> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | blocker | ||||||
| Priority: | P2 | CC: | ldv, pilot, shaba | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
|
Description
Andrei Bulava
2004-02-10 20:05:14 MSK
Система: ALT Linux Sisyphus (20040415) $ id snmp uid=112(snmp) gid=100(users) группы=100(users),19(proc) $ rpm -qv net-snmp net-snmp-5.1-alt3 После старта системы имею в /var/log/messages: Apr 20 20:50:00 adelaide crond[7276]: (root) CMD (/usr/bin/mrtg --user mrtg --group mrtg /etc/mrtg/mrtg-eth0.cfg) Apr 20 20:50:00 adelaide crond[7277]: (root) CMD (/usr/bin/mrtg --user mrtg --group mrtg /etc/mrtg/mrtg.cfg) Apr 20 20:50:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:50:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:50:02 adelaide snmpd: cannot open /proc/net/dev - continuing... Apr 20 20:50:02 adelaide last message repeated 20 times Apr 20 20:50:02 adelaide snmpd: snmpd: Cannot open /proc/net/arp Apr 20 20:50:02 adelaide last message repeated 2 times Apr 20 20:50:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:50:02 adelaide snmpd: cannot open /proc/net/dev - continuing... Apr 20 20:50:02 adelaide last message repeated 19 times Apr 20 20:50:02 adelaide snmpd: snmpd: Cannot open /proc/net/arp Apr 20 20:50:02 adelaide last message repeated 2 times Apr 20 20:50:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:50:03 adelaide last message repeated 3 times Apr 20 20:50:03 adelaide snmpd: cannot open /proc/net/dev - continuing... Apr 20 20:50:03 adelaide last message repeated 16 times Apr 20 20:50:03 adelaide snmpd: snmpd: Cannot open /proc/net/arp Apr 20 20:50:03 adelaide last message repeated 2 times Затем в адрес root приходит сообщение: Date: Tue, 20 Apr 2004 20:50:03 +0300 (EEST) From: Cron Daemon <root@adelaide.office> To: root@adelaide.office Subject: Cron <root@adelaide> /usr/bin/mrtg --user mrtg --group mrtg /etc/mrtg/mrtg-eth0.cfg WARNING: Could not match host:'public@localhost:' ref:'Descr' key:'eth0' ERROR: Target[localhost_eth0][_IN_] ' $target->[0]{$mode} ' did not eval into defined data ERROR: Target[localhost_eth0][_OUT_] ' $target->[0]{$mode} ' did not eval into defined data Тут же перезапускаю snmpd (service snmpd restart) и в /var/log/messages: Apr 20 20:52:48 adelaide snmpd: Received TERM or STOP signal... shutting down... Apr 20 20:52:49 adelaide snmpd: snmpd shutdown succeeded Apr 20 20:52:49 adelaide snmpd: snmpd startup succeeded Apr 20 20:52:50 adelaide snmpd: NET-SNMP version 5.1 Apr 20 20:55:00 adelaide crond[7487]: (root) CMD (/usr/bin/mrtg --user mrtg --group mrtg /etc/mrtg/mrtg-eth0.cfg) Apr 20 20:55:00 adelaide crond[7488]: (root) CMD (/usr/bin/mrtg --user mrtg --group mrtg /etc/mrtg/mrtg.cfg) Apr 20 20:55:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:55:02 adelaide snmpd: Received SNMP packet(s) from 127.0.0.1 Apr 20 20:55:02 adelaide snmpd: Connection from 127.0.0.1 Apr 20 20:55:02 adelaide last message repeated 12 times Сообщения от cron прекращаются, mrtg начинает давать показания. Т.е. налицо восстановление работоспособности snmpd. Но только до следующей перезагрузки. После перезагрузки картина повторяется с вероятностью 100%. Судя по тому, что до этого основной группой псевдопользователя snmp была gid=100(users), я решил, что на самом деле такая основная группа практически не играет какой-то специальной роли. Поэтому проблему удаётся решить с помощью комплекса из 2-х неотрывных друг от друга мер: 1) модифицировать псевдопользователя snmp т.о., чтобы $ id snmp uid=112(snmp) gid=19(proc) группы=19(proc) Для этого понадобится модифицировать spec-файл net-snmp, чтобы вторая строчка %post выглядела как /usr/sbin/usermod -g proc snmp &>/dev/null ||: 2) модифицировать /etc/init.d/snmpd наложением нижеследующего патча: --- /etc/init.d/snmpd.DISTRO 2004-02-18 15:35:09 +0200 +++ /etc/init.d/snmpd 2004-04-20 21:24:19 +0300 @@ -14,7 +14,7 @@ # Source function library. . /etc/init.d/functions -OPTIONS="-Ls DAEMON -Lf /dev/null -p /var/run/snmpd.pid -a -u `getuseruid snmp`" +OPTIONS="-Ls DAEMON -Lf /dev/null -p /var/run/snmpd.pid -a -u `getuseruid snmp` -g `id -g snmp`" PIDFILE=/var/run/snmpd.pid LOCKFILE=/var/lock/subsys/snmpd RETVAL=0 Created attachment 393 [details] Патч к /etc/init.d/snmpd В Additional Comment #1 From Andrei Bulava 2004-04-21 09:39 предлагаемый мною патч приведён в неудобном виде, поэтому прилагаю его отдельно. Предлагаю пропатчить на тему использования initgroups(3). С ldv согласен, именно это и является правильным. Хороший пример как это делается --- apache. В i/D/ ушёл: 51e642b0a1c2e6ee43346309818f44da net-snmp-5.1.1-alt1.1.src.rpm $ rpm -qp --lastchange net-snmp-5.1.1-alt1.1.src.rpm * Пнд Май 03 2004 Andrei Bulava <abulava@altlinux.ru> 5.1.1-alt1.1 - added 'initgroups' patch to use all groups of which 'snmp' user was a member - fixed init script & postinstall script to rollback changes which worked around lack of the initgroups function call in snmpd Патч достаточно прямолинейный: добавляет инициализацию списка вспомогательных групп путём вызова initgroups(3) (спасибо ldv@ и pilot@). Повторить все тонкости аналогичного места в apache (в части кроссплатформенности) - такой цели я не ставил. Тем не менее, и в таком виде патч, хочется верить, не вызовет отторжение у upstream ;-) как я понял этот пакет уже в Сизифе (In reply to comment #6) > как я понял этот пакет уже в Сизифе > Да, в Сизифе пакет с исправлением, предложенным в comment #1. Идеологически более правильный вариант исправления, описанный в comment #5, остался в Daedalus и в настоящий момент не ставится на систему с Sisyphus (после пересборки Сизифа с новым openssl). На своём тестовом стенде я использую самую свежую Сизифную версию, баг закрыт. Жаль только, если правильный патч так и не дойдёт до upstream :-( |
