Сервис upsdrv стартует раньше hotplug, из-за этого UPS с USB-интерфейсом не виден на момент старта upsdrv и драйвер не загружается. Как следствие - 1) если upsd настроен на единственный UPS (типично для десктопа), то следом за сбоем сервиса upsdrv следует сбой сервиса upsd; 2) если upsmon работает на этом же хосте (типично для десктопа), то в лог падает сообщение "UPS [ups@localhost]: connect failed: Connection failure: Connection refused"
Created attachment 592 [details] Исправление последовательности запуска сервисов Прилагаемый патч решает вопрос последовательности _запуска_ сервисов hotplug, upsdrv, upsd, upsmon. Что до последовательности _останова_ - при поверхностном взгляде практической проблемы с остановом hotplug до upsmon, upsd, upsdrv я не заметил. Но логичнее, наверное, довести начатое до конца, т.е. останавливать сервисы в последовательности, противоположной запуску: upsmon, upsd, upsdrv, hotplug.
Мои исправления не выдержали проверки reboot'ом :-( С моими исправлениями upsdrv стартует непосредственно после hotplug, но /dev/usb/hiddev0 не успевает появиться к моменту старта сервиса upsdrv. Пока даже не предполагаю, каким способом можно _правильно_ исправить ситуацию. Для моего конкретного случая сойдёт первый попавшийся костыль, но и тут ничего кроме банального sleep пока в голову не приходит.
*** Bug 5162 has been marked as a duplicate of this bug. ***
Я склоняюсь к тому, что надо что-то делать с hotplug. Может, запускать его раньше, может, ещё что-то делать.
А бесполезно с ним что-то делать - время, через которое появится USB-устройство, в общем случае не ограничено (например, при наличии нескольких USB-устройств распознавание их производится процессом khubd последовательно). Разве что запускать upsdrv из hotplug. Привязка к конкретным /dev/usb/* тоже никуда не годится - номера устройств плавают (в частности, даже при наличии только одного устройства при отключении и быстром подключении устройства для него может быть выделен новый номер, если программа недостаточно быстро закроет старый файл устройства). В 2.6 эту проблему может решить udev; в 2.4 с этим хуже.
*** Bug 7186 has been marked as a duplicate of this bug. ***
так... следующий блок бесперебойного пищания надо покупать с USB.
reassign to nut-driver Необходимо переделать алгоритм запуска сервиса upsdrv для ядра 2.6 В ядре 2.6 такой сервис должен запускаться из /etc/dev.d/DEVNAME/, где DEVNAME - соответствующее устройство, создаваемое при загрузке модуля для UPS. Там же он должен и останавливаться. К сожалению у меня нет UPS, соответственно патчи сделать не могу ;-(
Могу только добавить, что данная проблема присутствует не только с USB, но и с /dev/ttyS0 при использовании udev_static-addon-0.1-alt1 и udev-0.63-alt2
Предлагаю хотя бы перенести запуск upsd на несколько шагов позже hotplug, может хоть с /dev/ttyS? начнёт работать. Всё лучше, чем ничего.
Согласно комментарию #5, не начнёт.
Ну там речь о USB, а я о /dev/ttyS?
А откуда проблемы с /dev/ttyS? Если из-за недонастроенного udev'а, то это не здесь надо править.
udev тут не при чем. модуль 8250 для серийного порта грузится hotplug'ом. В приниципе скорее всего он загрузится, если попытаться открыть устройство в простом /dev/
Короче говоря, файл устройства и драйвер для него могут появится когда угодно или не появится вообще, и демон (в данном случае nut'овские драйвера) тут ничего сделать не может кроме как надеятся что файл устройства работает.
Да. Но здесь есть возможность запускать nut тогда, когда собственно появляется само устройство. Т.е. - убрать из сервисов и переместить запуск в udev udev дает возможность запускать любые приложения при появлении/удалении устройств
(In reply to comment #15) > Короче говоря, файл устройства и драйвер для него могут появится когда Я предлагаю передвинуть upsdrv/upsd и поставить после postfix (а то он ещё и письма слать не может при ошибке инициализации). Хуюе от этого вряд ли будет, а автору баги и мне, например, полегче.
(In reply to comment #17) > Я предлагаю передвинуть upsdrv/upsd и поставить после postfix (а то он ещё и > письма слать не может при ошибке инициализации). > Хуже от этого вряд ли будет, а автору баги и мне, например, полегче. Всегда найдётся человек, у которого upsdrv стартует быстрее, чем будет распознан USB UPS :-( BTW, в силу нетерпимости upsd к отсутствию upsdrv (иными словами, upsd сразу же вылетает с ошибкой, если на момент старта upsd не найдёт запущенного upsdrv), из udev придётся запускать сначала upsdrv, а затем upsd. Так что сервисом останется только upsmon :-|
* Mon Oct 10 2005 Dmitry V. Levin <ldv@altlinux> 2.0.2-alt1 - Updated to 2.0.2 release. - In startup scripts, changed chkconfig priorities to start later and stop earler (see #5211).
*** Bug 6329 has been marked as a duplicate of this bug. ***
ссылка весьма интересна. На мой взгляд стоит подождать, пока это пропихнут в upstream. Но на серверах такую схему я бы поостерёгся использовать.. или нам нужно думать, как разделить права на запуск утилиты управления питанием (например powersaved)
(In reply to comment #9) > Могу только добавить, что данная проблема присутствует не только с USB, но и с > /dev/ttyS0 при использовании udev_static-addon-0.1-alt1 и udev-0.63-alt2 А вот если /dev/ttyS0 положить в "железный" /dev, прям на rootfs -- тогда работаем. Кажется, я про это отдельный баг вешал.
Кстати, для такого "положить" давно собирался сделать dev-minimal (тж. #12020).
Пакет nut ищет мейнтейнера.
Пакет сборки amike@ залил в сизиф всё-таки я.
Просьба проверить на 2.6.x, если ещё представляется возможным; УМВР.
