[sisyphus] Обновление libusb и nut

[sisyphus] Обновление libusb и nut

[Ivan Adzhubey]

Приветствую!

После сегодняшнего обновления libusb перестал работать драйвер newhidups из 
пакета nu. Соответственно, и все остальные демоны управления UPS тоже. 
Наверное, надо пересобрать nut с новой libusb?

# service upsdrv status
newhidups is stopped

# service upsdrv restart
Stopping newhidups UPS driver service: Service newhidups is not running 
[PASSED]
Starting UPS drivers: Network UPS Tools: 0.28 USB communication driver 0.28 - 
core 0.30 (2.0.5)

Detected a UPS: American Power Conversion/Back-UPS ES 750 FW:841.I2 .D USB 
FW:I2
Using subdriver: APC/CyberPower HID 0.9
Network UPS Tools - UPS driver controller 2.0.5
Startup timer elapsed, continuing...    [FAILED]

# rpm -qa|fgrep libusb
libusb-0.9.3-alt2.0

# rpm -qa|fgrep nut-|sort
alterator-nut-0.2-alt17
libnut-0.0-alt0.505.1
nut-2.0.5-alt3.1
nut-driver-2.0.5-alt3.1
nut-driver-usb-2.0.5-alt3.1
nut-server-2.0.5-alt3.1

--Иван

Re: [sisyphus] Обновление libusb и nut

[Alexander Bokovoy]

2008/9/21 Ivan Adzhubey <iadzhubey@rics.bwh.harvard.edu>:
> Приветствую!
>
> После сегодняшнего обновления libusb перестал работать драйвер newhidups из
> пакета nu. Соответственно, и все остальные демоны управления UPS тоже.
> Наверное, надо пересобрать nut с новой libusb?
Рекомендую проверить права на соответствующие устройства. По умолчанию
upsdrv запускает драйвер в чруте, где нет на самом деле нужных
устройств, но в чрут он переходит после их определения. А дальше
начинается регулярное ресканирование шины:
# strace -p 27616
Process 27616 attached - interrupt to quit
select(7, [5 6], NULL, NULL, {1, 80000}) = 0 (Timeout)
open("/sys/bus/usb/devices",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file
or directory)
open("/sys/bus/usb/devices",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file
or directory)
open("/dev/bus/usb/001/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/001/003", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/002/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/003/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/003/002", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/004/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/005/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/007/001", O_RDWR)    = -1 ENOENT (No such file or directory)
open("/dev/bus/usb/006/001", O_RDWR)    = -1 ENOENT (No such file or directory)
write(5, "DATASTALE\n"..., 10)          = 10
time(NULL)                              = 1221966095
write(5, "DATAOK\n"..., 7)              = 7
select(7, [5 6], NULL, NULL, {2, 0}^C <unfinished ...>
Process 27616 detached
Естественно, все это "отваливается", потому что в чруте ничего нет.

Если не запускать его в чруте и дать права пользователю upsdrv на
работу с нужным USB устройством, то /var/log/messages должно быть
что-то вроде вот этого:
Sep 21 07:05:13 boii upsdrvctl: Network UPS Tools: 0.28 USB
communication driver 0.28 - core 0.30 (2.0.5)
Sep 21 07:05:13 boii upsdrvctl: Detected a UPS: American Power
Conversion/Back-UPS ES 525 FW:851.t3.I USB FW:t3
Sep 21 07:05:13 boii upsdrvctl: Using subdriver: APC/CyberPower HID 0.9
Sep 21 07:05:15 boii upsdrvctl: libusb couldn't open USB device
/dev/bus/usb/001/001: Permission denied.
Sep 21 07:05:15 boii upsdrvctl: libusb requires write access to USB
device nodes.
Sep 21 07:05:15 boii upsdrvctl: libusb couldn't open USB device
/dev/bus/usb/001/003: Permission denied.
Sep 21 07:05:15 boii upsdrvctl: libusb requires write access to USB
device nodes.
Sep 21 07:05:15 boii upsdrvctl: libusb couldn't open USB device
/dev/bus/usb/002/001: Permission denied.
Sep 21 07:05:15 boii upsdrvctl: libusb requires write access to USB
device nodes.
Sep 21 07:05:23 boii newhidups[27946]: Startup successful
Sep 21 07:05:23 boii upsdrvctl: Network UPS Tools - UPS driver controller 2.0.5
Sep 21 07:05:23 boii upsdrv: Starting UPS drivers: succeeded
Sep 21 07:05:35 boii upsd[27980]: Connected to UPS [ups]: ups
Sep 21 07:05:35 boii upsd: Connected to UPS [ups]: ups
Sep 21 07:05:35 boii upsd[27981]: Startup successful
Sep 21 07:05:35 boii upsd: upsd startup succeeded
Sep 21 07:05:44 boii upsmon[28000]: Startup successful
Sep 21 07:05:44 boii upsmon: UPS: ups@localhost (master) (power value 1)
Sep 21 07:05:44 boii upsmon: Using power down flag file /etc/killpower
Sep 21 07:05:44 boii upsmon: upsmon startup succeeded
Sep 21 07:05:44 boii upsd[27981]: Connection from 127.0.0.1
Sep 21 07:05:44 boii upsd[27981]: Client monuser@127.0.0.1 logged into UPS [ups]
Sep 21 07:05:52 boii upsd[27981]: Connection from 127.0.0.1
Sep 21 07:05:52 boii upsd[27981]: Client on 127.0.0.1 logged out

Сообщения от libusb -- нормальная реакция на невозможность открыть
несвязанные с нашей работой устройства на запись.

После чего все работает, но регулярное сканирование шины реализовано в
newhidups некорректно, из-за этого там утекает память:
Out of memory: kill process 27946 (newhidups) score 652587 or a child
Killed process 27946 (newhidups)

Я сейчас разбираюсь с кодом drivers/libusb.c в NUT.

-- 
/ Alexander Bokovoy

Re: [sisyphus] Обновление libusb и nut

[Ivan Adzhubey]

Добрый день, Александр!

On Saturday 20 September 2008 11:20:42 pm Alexander Bokovoy wrote:
> 2008/9/21 Ivan Adzhubey <iadzhubey@rics.bwh.harvard.edu>:
> > Приветствую!
> >
> > После сегодняшнего обновления libusb перестал работать драйвер newhidups
> > из пакета nu. Соответственно, и все остальные демоны управления UPS тоже.
> > Наверное, надо пересобрать nut с новой libusb?
>
> Рекомендую проверить права на соответствующие устройства.

Какие устройства? И как их проверять, если их все равно нет и не может быть в 
чруте? Или вы имеете в виду, что в режиме чрута оно вообще работать не может? 
А как раньше работало?

> По умолчанию 
> upsdrv запускает драйвер в чруте, где нет на самом деле нужных
> устройств, но в чрут он переходит после их определения.
> А дальше 
> начинается регулярное ресканирование шины:
<...skipped>
> Естественно, все это "отваливается", потому что в чруте ничего нет.

Еще раз, и как же это все раньше работало?

> Если не запускать его в чруте и дать права пользователю upsdrv на
> работу с нужным USB устройством,

Я настраивал средствами alterator-nut, не очень понимаю, зачем вообще тащить 
nut а чрут -- это что, настолько опасное устройство? Попробую чрут убрать...

> то /var/log/messages должно быть 
> что-то вроде вот этого:
> Sep 21 07:05:13 boii upsdrvctl: Network UPS Tools: 0.28 USB
> communication driver 0.28 - core 0.30 (2.0.5)
> Sep 21 07:05:13 boii upsdrvctl: Detected a UPS: American Power
> Conversion/Back-UPS ES 525 FW:851.t3.I USB FW:t3
> Sep 21 07:05:13 boii upsdrvctl: Using subdriver: APC/CyberPower HID 0.9
> Sep 21 07:05:15 boii upsdrvctl: libusb couldn't open USB device
> /dev/bus/usb/001/001: Permission denied.
> Sep 21 07:05:15 boii upsdrvctl: libusb requires write access to USB
> device nodes.
> Sep 21 07:05:15 boii upsdrvctl: libusb couldn't open USB device
> Sep 21 07:05:23 boii newhidups[27946]: Startup successful
> Sep 21 07:05:23 boii upsdrvctl: Network UPS Tools - UPS driver controller
> 2.0.5 Sep 21 07:05:23 boii upsdrv: Starting UPS drivers: succeeded
> Sep 21 07:05:35 boii upsd[27980]: Connected to UPS [ups]: ups
> Sep 21 07:05:35 boii upsd: Connected to UPS [ups]: ups
> Sep 21 07:05:35 boii upsd[27981]: Startup successful
> Sep 21 07:05:35 boii upsd: upsd startup succeeded
> Sep 21 07:05:44 boii upsmon[28000]: Startup successful
> Sep 21 07:05:44 boii upsmon: UPS: ups@localhost (master) (power value 1)
> Sep 21 07:05:44 boii upsmon: Using power down flag file /etc/killpower
> Sep 21 07:05:44 boii upsmon: upsmon startup succeeded
> Sep 21 07:05:44 boii upsd[27981]: Connection from 127.0.0.1
> Sep 21 07:05:44 boii upsd[27981]: Client monuser@127.0.0.1 logged into UPS
> [ups] Sep 21 07:05:52 boii upsd[27981]: Connection from 127.0.0.1
> Sep 21 07:05:52 boii upsd[27981]: Client on 127.0.0.1 logged out
>
> Сообщения от libusb -- нормальная реакция на невозможность открыть
> несвязанные с нашей работой устройства на запись.

Странно, но до апдейта никаких сообщений о permission denied от libusb я не 
наблюдал. А как выставлять права на устройство, оно же создается динамически 
udev'ом? Это надо в скрипты настройки udevd лезть? Кошмар...

> После чего все работает, но регулярное сканирование шины реализовано в
> newhidups некорректно, из-за этого там утекает память:
> Out of memory: kill process 27946 (newhidups) score 652587 or a child
> Killed process 27946 (newhidups)
>
> Я сейчас разбираюсь с кодом drivers/libusb.c в NUT.

Утечек памяти у меня тоже не наблюдалось, по крайней мере таких, чтобы оно 
отваливалось по недостатку памяти. Платформа x86_64 если это имеет значение.

--Иван

Re: [sisyphus] Обновление libusb и nut

[Alexander Bokovoy]

2008/9/21 Ivan Adzhubey <iadzhubey@rics.bwh.harvard.edu>:
>> Рекомендую проверить права на соответствующие устройства.
> Какие устройства? И как их проверять, если их все равно нет и не может быть в
> чруте? Или вы имеете в виду, что в режиме чрута оно вообще работать не может?
> А как раньше работало?
Сам удивляюсь.

>> Сообщения от libusb -- нормальная реакция на невозможность открыть
>> несвязанные с нашей работой устройства на запись.
> Странно, но до апдейта никаких сообщений о permission denied от libusb я не
> наблюдал. А как выставлять права на устройство, оно же создается динамически
> udev'ом? Это надо в скрипты настройки udevd лезть? Кошмар...
libusb сканирует шину USB. Делается это дважды: вначале сканируются
/dev/bus/usb/*/*, затем -- если ничего не найдено -- сканируется
/proc/bus/usb/*. При попытке получить информацию об устройстве,
newhidups вначале открывает его, а затем читает дескриптор устройства.
Для этого ему нужно открыть устройство на запись (он посылает в
устройство запрос о его состоянии). В libusb 0.1 позволялось открывать
устройства, для которых нет прав на запись, а потом получить
невозможность записать при первой же записи. На самом деле, для чтения
дескриптора вообще не надо открывать его на запись, о чем libusb 0.9.3
и говорит. Раньше такое сообщение в libusb 0.1.12 отсутствовало,
потому его Вы и не видели. Это нормальное поведение, оно отражено в
описании разницы libusb-compat и libusb 0.1.12, и не представляет
проблемы.

Права естественно надо настраивать. Например, вот так:
/etc/udev/rules.d/60-nut-usb.rules
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<
ACTION!="add", GOTO="nut_end"
SUBSYSTEM!="usb|usb_device", GOTO="nut_end"

GROUP="upsdrv"
MODE="0660"
SYSFS{idVendor}=="051d", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="0764", SYSFS{idProduct}=="0005"
SYSFS{idVendor}=="0764", SYSFS{idProduct}=="0501"
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="2005"
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="1003"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0980"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0900"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0912"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0551"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0751"
SYSFS{idVendor}=="0592", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="06da", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="0001"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff"

LABEL="nut_end"
--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8

Предлагаю прислать идентификаторы (в багзилу) и собрать их как список
SYSFS(idVendor} и SYSFS{idProduct} в пакете nut-driver-usb. В
указанном файле нужно только добавлять строчки с SYSFS, все
поддерживаемое текущим nut я уже добавил.

>> После чего все работает, но регулярное сканирование шины реализовано в
>> newhidups некорректно, из-за этого там утекает память:
>> Out of memory: kill process 27946 (newhidups) score 652587 or a child
>> Killed process 27946 (newhidups)
>>
>> Я сейчас разбираюсь с кодом drivers/libusb.c в NUT.
>
> Утечек памяти у меня тоже не наблюдалось, по крайней мере таких, чтобы оно
> отваливалось по недостатку памяти. Платформа x86_64 если это имеет значение.
В данном случае платформа роли не играет. Я разбираюсь с кодом.

-- 
/ Alexander Bokovoy