snmpd[890121]: Cannot statfs /var/lib/vz/root/1020 : Permission denied snmpd[890121]: Cannot statfs /var/lib/vz/root/1020/proc : Permission denied snmpd[890121]: Cannot statfs /var/lib/vz/root/1020/sys : Permission denied в snmpd.conf пробовал ignoredisk /dev/md5 disk / 10000 disk <->/home<->10% disk<-->/usr<-->10% #disk<-->/var<-->10% #disk<->/var/lib/vz<--->10% без результата, в итоге вообще не выдает информацию о дисках
Покажите пожалуйста команду с помощью которой вы проверяете?
Не могу воспроизвести. У меня отдает все. [root@dubrline ~]# snmpwalk -v 1 -c "public" localhost dskUsed UCD-SNMP-MIB::dskUsed.1 = INTEGER: 10120084 UCD-SNMP-MIB::dskUsed.2 = INTEGER: 27638788 UCD-SNMP-MIB::dskUsed.3 = INTEGER: 10120084 UCD-SNMP-MIB::dskUsed.4 = INTEGER: 27638788 UCD-SNMP-MIB::dskUsed.5 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.6 = INTEGER: 548 UCD-SNMP-MIB::dskUsed.7 = INTEGER: 524 UCD-SNMP-MIB::dskUsed.8 = INTEGER: 108 UCD-SNMP-MIB::dskUsed.9 = INTEGER: 330019536 [root@dubrline ~]# snmpwalk -v 1 -c "public" localhost dskPath UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: /mnt/disk UCD-SNMP-MIB::dskPath.3 = STRING: / UCD-SNMP-MIB::dskPath.4 = STRING: /mnt/disk UCD-SNMP-MIB::dskPath.5 = STRING: /dev UCD-SNMP-MIB::dskPath.6 = STRING: /run UCD-SNMP-MIB::dskPath.7 = STRING: /dev/shm UCD-SNMP-MIB::dskPath.8 = STRING: /tmp UCD-SNMP-MIB::dskPath.9 = STRING: /home [root@dubrline ~]# uname -a Linux dubrline.localdomain 2.6.32-ovz-el-alt32 #1 SMP Tue Sep 6 09:19:05 UTC 2011 i686 GNU/Linux [root@dubrline ~]# rpm -qa| grep snmpd net-snmp-snmpd-5.7.1-alt1.rc1 да, в логе ругань есть, но на аэродинамику не влияет. Скорее всего это связано с тем что теперь на хардноде видны смонтированные для впс разделы.
(В ответ на комментарий №2) > Не могу воспроизвести. У меня отдает все. машина с проблемой: 2.6.32-ovz-el-alt13 net-snmp-snmpd-5.7.1-alt1.rc1 /usr/sbin/snmpd -LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a -u snmp -g snmp snmpwalk -v 3 -a md5 -A xxx -l authNoPriv -u cacti 10.1.0.6 dskUsed UCD-SNMP-MIB::dskUsed.1 = INTEGER: 391600 UCD-SNMP-MIB::dskUsed.2 = INTEGER: 813940 UCD-SNMP-MIB::dskUsed.3 = INTEGER: 249892332 UCD-SNMP-MIB::dskUsed.4 = INTEGER: 560 UCD-SNMP-MIB::dskUsed.5 = INTEGER: 957408 Timeout: No Response from 10.1.0.6 snmpwalk -v 3 -a md5 -A xxx -l authNoPriv -u cacti 10.1.0.6 dskPath UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: /home UCD-SNMP-MIB::dskPath.3 = STRING: /srv UCD-SNMP-MIB::dskPath.4 = STRING: /tmp UCD-SNMP-MIB::dskPath.5 = STRING: /usr Timeout: No Response from 10.1.0.6 snmpwalk -v 3 -a md5 -A xxx -l authNoPriv -u cacti 10.1.0.6 dskPath UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: /home Timeout: No Response from 10.1.0.6 если запустить подряд несколько раз, то выдает то / и /home; то все и медленно до неприличия рядом стоит машинка 2.6.32-ovz-el-alt13 net-snmp-snmpd-5.6.1-alt1.1 /usr/sbin/snmpd -LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a -u snmp -g snmp df -h | grep vz /var/lib/vz/private/1051 9.6G 1020M 7.8G 12% /var/lib/vz/root/1051 /var/lib/vz/private/1017 10G 6.1G 4.0G 61% /var/lib/vz/root/1017 /var/lib/vz/private/1009 1.0G 522M 503M 51% /var/lib/vz/root/1009 snmpwalk -v 3 -a md5 -A xxx -l authNoPriv -u cacti tcp:10.1.0.4 dskPath UCD-SNMP-MIB::dskPath.1 = STRING: /dev UCD-SNMP-MIB::dskPath.2 = STRING: / UCD-SNMP-MIB::dskPath.3 = STRING: /proc UCD-SNMP-MIB::dskPath.4 = STRING: /sys UCD-SNMP-MIB::dskPath.5 = STRING: /dev/pts UCD-SNMP-MIB::dskPath.6 = STRING: /dev/shm UCD-SNMP-MIB::dskPath.7 = STRING: /tmp UCD-SNMP-MIB::dskPath.8 = STRING: /boot UCD-SNMP-MIB::dskPath.9 = STRING: /home UCD-SNMP-MIB::dskPath.10 = STRING: /usr UCD-SNMP-MIB::dskPath.11 = STRING: /var UCD-SNMP-MIB::dskPath.12 = STRING: /var/lib/vz мгновенно и без ругани в логах >с тем что теперь на хардноде видны смонтированные для впс разделы. видны на обеих HW
(В ответ на комментарий №3) пересобрал net-snmp-snmpd-5.6.1.1-alt3 полет нормальный, сразу все вылечилось.
Спасибо. Поэтому и не собираю 5.7 в бранчи. Посмотрю.
Проверьте пожалуйста на 5.7.1-alt2 Я локально у себя не вижу никаких задержек :(
(В ответ на комментарий №6) > Проверьте пожалуйста на 5.7.1-alt2 > Я локально у себя не вижу никаких задержек :( проверила локально 2.6.32-ovz-el-alt31 net-snmp-snmpd-5.7.1-alt3 df -h Filesystem Size Used Avail Use% Mounted on udevfs 5.0M 200K 4.9M 4% /dev /dev/md2 1004M 203M 750M 22% / shmfs 3.9G 44K 3.9G 1% /dev/shm tmpfs 3.9G 0 3.9G 0% /tmp /dev/md1 122M 16M 100M 14% /boot /dev/md3 3.0G 566M 2.3G 20% /usr /dev/md4 9.9G 384M 9.0G 5% /var /dev/mapper/vg00-vz 197G 35G 153G 19% /var/lib/vz /dev/mapper/vg00-libvirt 44G 8.7G 33G 22% /var/lib/libvirt /var/lib/vz/private/1029 1.0G 632M 393M 62% /var/lib/vz/root/1029 /var/lib/vz/private/1050 1.0G 454M 571M 45% /var/lib/vz/root/1050 /var/lib/vz/private/1053 20G 12G 8.5G 58% /var/lib/vz/root/1053 tmpfs 256M 0 256M 0% /var/lib/vz/root/1050/tmp tmpfs 512M 0 512M 0% /var/lib/vz/root/1053/tmp /var/lib/vz/private/1021 2.0G 1.1G 1010M 51% /var/lib/vz/root/1021 tmpfs 512M 4.0K 512M 1% /var/lib/vz/root/1021/tmp /var/lib/vz/private/1034 10G 6.6G 3.5G 66% /var/lib/vz/root/1034 /var/lib/vz/private/1010 1.0G 764M 261M 75% /var/lib/vz/root/1010 grep disk /etc/snmp/snmpd.conf disk / 10000 disk<-->/srv<-->10% disk<-->/usr<-->10% disk<-->/var<-->10% disk<-->/var/lib/vz<--->10% disk<-->/var/lib/libvirt<------>10% disk<-->/home<->10% snmpwalk -v 3 -a md5 -A xxxx -l authNoPriv -u xxx 10.1.0.9 dskUsed UCD-SNMP-MIB::dskUsed.1 = INTEGER: 207864 UCD-SNMP-MIB::dskUsed.2 = INTEGER: 200 UCD-SNMP-MIB::dskUsed.3 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.4 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.5 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.6 = INTEGER: 44 UCD-SNMP-MIB::dskUsed.7 = INTEGER: 0 Timeout: No Response from 10.1.0.9 между каждой выводимой строчкой timeout на 2-3 сек. в логах snmpd[984437]: Cannot statfs /var/lib/vz/root/1050/dev/pts : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1050/tmp : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1053/dev/pts : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1053/tmp : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1021 : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1021/proc : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1021/sys : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1021/dev/pts : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1021/tmp : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1034 : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1034/proc : Permission denied snmpd[984437]: Cannot statfs /var/lib/vz/root/1034/sys : Permission denied ну и так далее rpm -iUhv net-snmp-snmpd-5.6.1.1-alt3.x86_64.rpm --oldpackage service snmpd restart snmpwalk -v 3 -a md5 -A xxx -l authNoPriv -u xxx 10.1.0.9 dskUsed UCD-SNMP-MIB::dskUsed.1 = INTEGER: 207864 UCD-SNMP-MIB::dskUsed.2 = INTEGER: 200 UCD-SNMP-MIB::dskUsed.3 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.4 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.5 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.6 = INTEGER: 44 UCD-SNMP-MIB::dskUsed.7 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.8 = INTEGER: 15680 UCD-SNMP-MIB::dskUsed.9 = INTEGER: 578912 UCD-SNMP-MIB::dskUsed.10 = INTEGER: 392736 UCD-SNMP-MIB::dskUsed.11 = INTEGER: 35814764 UCD-SNMP-MIB::dskUsed.12 = INTEGER: 9026484 Мгновенно и без ругани в логах.
Вообщем проблема в правах. Если запускать snmpd из-под root то ошибок нет и все работает быстро. Или можно пользователя snmp добавить в группу _vzctl и на /var/lib/vz/root поставить права 0750. Только я не уверен что установка таких прав ничего не сломает. Помнится была ошибка когда хешер отказывался работать при не правильных правах. Нужно корифеев спросить.
(В ответ на комментарий №8) > Вообщем проблема в правах. > Если запускать snmpd из-под root то ошибок нет и все работает быстро. > Или можно пользователя snmp добавить в группу _vzctl и на /var/lib/vz/root > поставить права 0750. Только я не уверен что установка таких прав ничего не > сломает. Помнится была ошибка когда хешер отказывался работать при не > правильных правах. Нужно корифеев спросить. Версия net-snmp-snmpd-5.6.1 работает без внесения snmp в группу _vzctl. Параметр disk/ignoredisk почему то не влияет, а по идеи должен, зачем он определяет размер той точки ФС которая не указана. Зачем ему права vzctl чтобы определить размер диска, он что запускает du -s /var/lib/vz ?, хотя логичнее df.
в общем виновник найден как я вижу. Все из-за ссылки /etc/mtab -> /proc/mounts, которую поставили зачем-то. $ rpmquery -f /etc/mtab mount-2.20.0-alt2 $ rpmquery -f /etc/mtab --changelog |grep -FC2 /etc/mtab * Mon Feb 28 2011 Alexey Shabalin <shaba@altlinux> 2.19.0-alt3.20110215 - /etc/mtab as symlink to /proc/mounts - build with selinux support - build with audit support Если /etc/mtab удалить и ребутнуть, то /etc/mtab запоняется правильно и snmpd начинает работать корректно. По-видимому в новой версии поменялась логика, и он смотрит в /etc/mtab что показывать, а что нет. Багу на mount я повесил https://bugzilla.altlinux.org/26860 Посмотрим скажет ли что-то Алексей.
(In reply to comment #7) > проверила локально Ба, женского полку прибыло :) (In reply to comment #9) > > Если запускать snmpd из-под root то ошибок нет и все работает быстро. > Версия net-snmp-snmpd-5.6.1 работает без внесения snmp в группу _vzctl. Сравните ps auxww | grep snmpd в обоих случаях -- насколько понимаю Славу, в 5.7 переехали на сброс привилегий. > Зачем ему права vzctl чтобы определить размер диска, он что запускает du -s > /var/lib/vz ?, хотя логичнее df. Сравните вывод df, запущенного с правами root (как 5.6) и от-кого-там-бегает 5.7... (In reply to comment #10) > в общем виновник найден как я вижу. Все из-за ссылки > /etc/mtab -> /proc/mounts, которую поставили зачем-то. Виновник скорее является взаимодействием ряда факторов: - при симлинке на /proc/mounts эффект mount -n (vzctl) множится на ноль; - snmpd бежит по всему /etc/mtab, а не только указанным префиксам; - монтируемые под /var/lib/vz файловые системы ограниченно доступны; - snmpd в 5.7 запускается с недостаточными для опроса /var/lib/vz/* правами. Я бы дёргал апстрим -- полагаться на то, что любую запись в любом /etc/mtab будет возможно statfs()нуть без получения EPERM, в общем случае нельзя. > Если /etc/mtab удалить и ребутнуть, то /etc/mtab запоняется правильно > и snmpd начинает работать корректно. По-видимому в новой версии поменялась > логика, и он смотрит в /etc/mtab что показывать, а что нет. http://lists.altlinux.org/pipermail/devel/2012-January/193181.html > Багу на mount я повесил https://bugzilla.altlinux.org/26860 > Посмотрим скажет ли что-то Алексей. http://lists.altlinux.org/pipermail/devel/2012-January/193192.html http://lists.altlinux.org/pipermail/devel/2012-January/193193.html
(В ответ на комментарий №11) > (In reply to comment #7) > > проверила локально > Ба, женского полку прибыло :) :) > > (In reply to comment #9) > > > Если запускать snmpd из-под root то ошибок нет и все работает быстро. > > Версия net-snmp-snmpd-5.6.1 работает без внесения snmp в группу _vzctl. > Сравните ps auxww | grep snmpd в обоих случаях -- насколько понимаю Славу, в > 5.7 переехали на сброс привилегий. rpm -q net-snmp-snmpd net-snmp-snmpd-5.7.1-alt6 ps auxww | grep snmpd snmp 3735 0.0 0.2 16648 2600 ? S Jan23 45:51 /usr/sbin/snmpd -LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a -u snmp -g snmp rpm -q net-snmp-snmpd net-snmp-snmpd-5.6.1.1-alt3 ps auxww | grep snmpd snmp 7661 0.0 0.0 71668 3712 ? S Feb21 4:18 /usr/sbin/snmpd -LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a -u snmp -g snmp su snmp -c "df" -s /bin/bash df: `/var/lib/vz/root/1010': Permission denied df: `/var/lib/vz/root/1010/sys': Permission denied df: `/var/lib/vz/root/1013': Permission denied df: `/var/lib/vz/root/1013/sys': Permission denied и т.д. ll /etc/mtab lrwxrwxrwx 1 root root 12 Feb 7 13:14 /etc/mtab -> /proc/mounts и при этом на 5.6 полёт отличный > > > Зачем ему права vzctl чтобы определить размер диска, он что запускает du -s > > /var/lib/vz ?, хотя логичнее df. > Сравните вывод df, запущенного с правами root (как 5.6) и от-кого-там-бегает > 5.7... > > (In reply to comment #10) > > в общем виновник найден как я вижу. Все из-за ссылки > > /etc/mtab -> /proc/mounts, которую поставили зачем-то. > Виновник скорее является взаимодействием ряда факторов: > - при симлинке на /proc/mounts эффект mount -n (vzctl) множится на ноль; > - snmpd бежит по всему /etc/mtab, а не только указанным префиксам; > - монтируемые под /var/lib/vz файловые системы ограниченно доступны; > - snmpd в 5.7 запускается с недостаточными для опроса /var/lib/vz/* правами. > > Я бы дёргал апстрим -- полагаться на то, что любую запись в любом /etc/mtab > будет возможно statfs()нуть без получения EPERM, в общем случае нельзя. > > > Если /etc/mtab удалить и ребутнуть, то /etc/mtab запоняется правильно > > и snmpd начинает работать корректно. По-видимому в новой версии поменялась > > логика, и он смотрит в /etc/mtab что показывать, а что нет. > http://lists.altlinux.org/pipermail/devel/2012-January/193181.html > > > Багу на mount я повесил https://bugzilla.altlinux.org/26860 > > Посмотрим скажет ли что-то Алексей. > http://lists.altlinux.org/pipermail/devel/2012-January/193192.html > http://lists.altlinux.org/pipermail/devel/2012-January/193193.html
Тогда тем более в апстрим.
А точно это сейчас проявляется в сизифе? в p7 проявляется, но в p7 я бы предложил обновить net-snmp, там добавляли исключения на simfs.
(В ответ на комментарий №14) > А точно это сейчас проявляется в сизифе? > в p7 проявляется, но в p7 я бы предложил обновить net-snmp, там добавляли > исключения на simfs. Я на хостах убиваю линк /etc/mtab. (решает проблему, мне не нужно в статистике всё, что монтируется после загрузки) Вернул линк mtab на /proc/mounts service snmpd reload #snmpwalk .... dskPath UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: / ... UCD-SNMP-MIB::dskPath.12 = STRING: /run UCD-SNMP-MIB::dskPath.19 = STRING: /var/lib/vz/root/1047 UCD-SNMP-MIB::dskPath.20 = STRING: /var/lib/vz/root/1047/tmp # snmpwalk .... dskUsed UCD-SNMP-MIB::dskUsed.1 = INTEGER: 411060 UCD-SNMP-MIB::dskUsed.2 = INTEGER: 411060 ... UCD-SNMP-MIB::dskUsed.11 = INTEGER: 36881924 UCD-SNMP-MIB::dskUsed.12 = INTEGER: 928 UCD-SNMP-MIB::dskUsed.19 = INTEGER: 0 UCD-SNMP-MIB::dskUsed.20 = INTEGER: 0 Вроде работает, покрайней мере опрс snmp не тормозит, но в логах на хосте, спамит ... Cannot statfs /var/lib/vz/root/1047/tmp: Permission denied ... id snmp uid=106(snmp) gid=19(proc) groups=19(proc) как я понял simfs не игнорируется (хотя часть контейнеров уже в ploop на него тоже спамит) snmpd.conf дэфолтный cat /etc/mtab ... /var/lib/vz/private/1047 /var/lib/vz/root/1047 simfs rw,relatime 0 0 proc /var/lib/vz/root/1047/proc proc rw,nosuid,noexec,relatime 0 0 sysfs /var/lib/vz/root/1047/sys sysfs rw,relatime 0 0 devpts /var/lib/vz/root/1047/dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0 tmpfs /var/lib/vz/root/1047/tmp tmpfs rw,nosuid,relatime 0 0 ... uname -r 2.6.32-ovz-el-alt122 net-snmp-snmpd-5.7.2-alt5
Сейчас столкнулся с тем, что на сизифе: =========================================================== root@nzp2 ~ # egrep "^(Uid|Gid)" /proc/`pidof snmptrapd`/task/`pidof snmptrapd`/status Uid: 487 487 487 487 Gid: 0 0 0 0 root@nzp2 ~ # ps auxww|grep snmptrapd snmp 10738 0.0 0.5 103988 10816 ? Ss 00:29 0:00 /usr/sbin/snmptrapd -Ls DAEMON -Lf /dev/null -p /var/run/snmptrapd.pid -a -u snmp -g snmp =========================================================== Т.е. запуск с -g snmp - не работает, по факту запускается от рута. Это даже документировано: =========================================================== root@nzp2 ~ # snmptrapd --help 2>&1 |grep -- -g -g GID change to this numeric gid after opening =========================================================== если для -g использовать цифровой gid группы snmp - статус процесса меняется, Gid становится равным 487. Моя теория в том, что в 5.6.1-alt1 аналогичная ситуация имела место и с ключом -u, так что фактически snmpd/snmptrapd работал(и) полностью от рута, несмотря на ключи запуска -u snmp -g snmp. Поэтому и читались без проблем любые точки монтирования. Насколько я понимаю, -g починено сейчас в апстримном 5.7.3 (судя по коду в agent/snmpd.c, но 100% не скажу - апстримный git зажимается злобным SF.net). Соответственно, после обновления net-snmp в сизифе (видимо, придется этим заняться, если никто более грамотный не вызовется) snmpd и не будет показывать данных по SimFS/Ploop, но возможно перестанет ругаться на SimFS. Объезд для snmpd, видимо, прост: раскомментировать в /e/sysconfig/snmpd строку с OPTIONS по умолчанию И убрать оттуда ключи -u и -g (для запуска snmpd от рута). К сожалению, для snmptrapd такого варианта не предусмотрено.
(В ответ на комментарий №16) > К сожалению, для snmptrapd такого варианта не предусмотрено. (сбоку) Может, заодно и предусмотреть, или там нет -u/-g? PS: периодический интерес в net-snmp бывает, но оборудования плюс необходимости его мониторить у меня обычно бывало немного...
(В ответ на комментарий №17) > > К сожалению, для snmptrapd такого варианта не предусмотрено. > (сбоку) Может, заодно и предусмотреть, или там нет -u/-g? Наоборот, есть. И как раз с snmptrapd натолкнулся, что на деле у него Gid=0. Пришлось городить объезд в snmptt. https://bugzilla.altlinux.org/show_bug.cgi?id=30927 в общем.
