#26292 – ядро openvz, snmpd перестал выдавать информацию о дисках на хост системе

Bug 26292 - ядро openvz, snmpd перестал выдавать информацию о дисках на хост системе

Summary: ядро openvz, snmpd перестал выдавать информацию о дисках на хост системе

Status:	CLOSED WONTFIX

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	net-snmp-snmpd (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 critical
Assignee:	Alexey Shabalin
QA Contact:	qa-sisyphus

URL:
Keywords:

Depends on:	26860
Blocks:
	Show dependency tree

Reported:	2011-09-13 20:51 MSK by Chess
Modified:	2026-08-29 22:53 MSK (History)
CC List:	5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Chess 2011-09-13 20:51:24 MSK

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%

без результата, в итоге вообще не выдает информацию о дисках

Comment 1

Slava Dubrovskiy 2011-09-14 06:08:02 MSK

Покажите пожалуйста команду с помощью которой вы проверяете?

Comment 2

Slava Dubrovskiy 2011-09-14 08:12:36 MSK

Не могу воспроизвести. У меня отдает все.

[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

да, в логе ругань есть, но на аэродинамику не влияет. Скорее всего это связано с тем что теперь на хардноде видны смонтированные для впс разделы.

Comment 3

Chess 2011-09-15 09:21:31 MSK

(В ответ на комментарий №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

Comment 4

Chess 2011-09-15 13:36:48 MSK

(В ответ на комментарий №3)

пересобрал net-snmp-snmpd-5.6.1.1-alt3

полет нормальный, сразу все вылечилось.

Comment 5

Slava Dubrovskiy 2011-09-15 18:44:55 MSK

Спасибо. Поэтому и не собираю 5.7 в бранчи.
Посмотрю.

Comment 6

Slava Dubrovskiy 2011-10-09 09:25:00 MSK

Проверьте пожалуйста на 5.7.1-alt2
Я локально у себя не вижу никаких задержек :(

Comment 7

Chess 2011-10-25 18:28:42 MSK

(В ответ на комментарий №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

Мгновенно и без ругани в логах.

Comment 8

Slava Dubrovskiy 2011-12-22 08:57:50 MSK

Вообщем проблема в правах.
Если запускать snmpd из-под root то ошибок нет и все работает быстро.
Или можно пользователя snmp добавить в группу _vzctl и на /var/lib/vz/root поставить права 0750. Только я не уверен что установка таких прав ничего не сломает. Помнится была ошибка когда хешер отказывался работать при не правильных правах. Нужно корифеев спросить.

Comment 9

Chess 2011-12-22 18:42:14 MSK

(В ответ на комментарий №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.

Comment 10

Slava Dubrovskiy 2012-01-29 08:02:39 MSK

в общем виновник найден как я вижу. Все из-за ссылки /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
Посмотрим скажет ли что-то Алексей.

Comment 11

Michael Shigorin 2012-02-29 12:56:46 MSK

(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

Comment 12

Chess 2012-02-29 13:40:08 MSK

(В ответ на комментарий №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

Comment 13

Michael Shigorin 2012-02-29 13:47:15 MSK

Тогда тем более в апстрим.

Comment 14

Alexey Shabalin 2014-09-03 14:35:22 MSK

А точно это сейчас проявляется в сизифе?
в p7 проявляется, но в p7 я бы предложил обновить net-snmp, там добавляли исключения на simfs.

Comment 15

Chess 2014-09-06 14:37:15 MSK

(В ответ на комментарий №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

Comment 16

Evgenii Terechkov 2015-04-07 20:55:05 MSK

Сейчас столкнулся с тем, что на сизифе:
===========================================================
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 такого варианта не предусмотрено.

Comment 17

Michael Shigorin 2015-04-09 18:43:41 MSK

(В ответ на комментарий №16)
> К сожалению, для snmptrapd такого варианта не предусмотрено.
(сбоку) Может, заодно и предусмотреть, или там нет -u/-g?

PS: периодический интерес в net-snmp бывает, но оборудования плюс необходимости его мониторить у меня обычно бывало немного...

Comment 18

Evgenii Terechkov 2015-04-09 19:17:45 MSK

(В ответ на комментарий №17)
> > К сожалению, для snmptrapd такого варианта не предусмотрено.
> (сбоку) Может, заодно и предусмотреть, или там нет -u/-g?

Наоборот, есть. И как раз с snmptrapd натолкнулся, что на деле у него Gid=0. Пришлось городить объезд в snmptt.

https://bugzilla.altlinux.org/show_bug.cgi?id=30927 в общем.

Comment 19

Anton Farygin 2026-08-29 22:53:43 MSK

Проблема специфична для OpenVZ-ядра, которых в ALT больше нет; net-snmp с тех пор обновился с 5.4 до 5.9.4. На современных ядрах snmpd информацию о дисках отдаёт. Закрываю как неактуальный.