Bug 26292 - ядро openvz, snmpd перестал выдавать информацию о дисках на хост системе
: ядро openvz, snmpd перестал выдавать информацию о дисках на хост системе
Status: ASSIGNED
: Sisyphus
(All bugs in Sisyphus/net-snmp-snmpd)
: unstable
: all Linux
: P3 critical
Assigned To:
:
:
:
: 26860
:
  Show dependency tree
 
Reported: 2011-09-13 20:51 by
Modified: 2015-04-09 19:17 (History)


Attachments


Note

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


Description From 2011-09-13 20:51:24
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 From 2011-09-14 06:08:02 -------
Покажите пожалуйста команду с помощью которой вы проверяете?
------- Comment #2 From 2011-09-14 08:12:36 -------
Не могу воспроизвести. У меня отдает все.

[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 From 2011-09-15 09:21:31 -------
(В ответ на комментарий №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 From 2011-09-15 13:36:48 -------
(В ответ на комментарий №3)

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

полет нормальный, сразу все вылечилось.
------- Comment #5 From 2011-09-15 18:44:55 -------
Спасибо. Поэтому и не собираю 5.7 в бранчи.
Посмотрю.
------- Comment #6 From 2011-10-09 09:25:00 -------
Проверьте пожалуйста на 5.7.1-alt2
Я локально у себя не вижу никаких задержек :(
------- Comment #7 From 2011-10-25 18:28:42 -------
(В ответ на комментарий №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 From 2011-12-22 08:57:50 -------
Вообщем проблема в правах.
Если запускать snmpd из-под root то ошибок нет и все работает быстро.
Или можно пользователя snmp добавить в группу _vzctl и на /var/lib/vz/root
поставить права 0750. Только я не уверен что установка таких прав ничего не
сломает. Помнится была ошибка когда хешер отказывался работать при не
правильных правах. Нужно корифеев спросить.
------- Comment #9 From 2011-12-22 18:42:14 -------
(В ответ на комментарий №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 From 2012-01-29 08:02:39 -------
в общем виновник найден как я вижу. Все из-за ссылки /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 From 2012-02-29 12:56:46 -------
(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 From 2012-02-29 13:40:08 -------
(В ответ на комментарий №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 From 2012-02-29 13:47:15 -------
Тогда тем более в апстрим.
------- Comment #14 From 2014-09-03 14:35:22 -------
А точно это сейчас проявляется в сизифе?
в p7 проявляется, но в p7 я бы предложил обновить net-snmp, там добавляли
исключения на simfs.
------- Comment #15 From 2014-09-06 14:37:15 -------
(В ответ на комментарий №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 From 2015-04-07 20:55:05 -------
Сейчас столкнулся с тем, что на сизифе:
===========================================================
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 From 2015-04-09 18:43:41 -------
(В ответ на комментарий №16)
> К сожалению, для snmptrapd такого варианта не предусмотрено.
(сбоку) Может, заодно и предусмотреть, или там нет -u/-g?

PS: периодический интерес в net-snmp бывает, но оборудования плюс необходимости
его мониторить у меня обычно бывало немного...
------- Comment #18 From 2015-04-09 19:17:45 -------
(В ответ на комментарий №17)
> > К сожалению, для snmptrapd такого варианта не предусмотрено.
> (сбоку) Может, заодно и предусмотреть, или там нет -u/-g?

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

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