5211 2004-09-14 11:21:45 +0400 сбой запуска сервиса upsdrv для UPS с интерфейсом USB 2012-05-05 23:12:01 +0400 1 1 4 Development Sisyphus nut-driver unstable all Linux CLOSED WORKSFORME http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-March/000772.html P2 normal --- 7085 14491 1 abulava yuk alexsid amike eostapets lav ldv migor mike rider serpiph sr vsu qa-sisyphus oldest_to_newest 18800 0 abulava 2004-09-14 11:21:45 +0400 Сервис upsdrv стартует раньше hotplug, из-за этого UPS с USB-интерфейсом не виден на момент старта upsdrv и драйвер не загружается. Как следствие - 1) если upsd настроен на единственный UPS (типично для десктопа), то следом за сбоем сервиса upsdrv следует сбой сервиса upsd; 2) если upsmon работает на этом же хосте (типично для десктопа), то в лог падает сообщение "UPS [ups@localhost]: connect failed: Connection failure: Connection refused" 18801 1 592 abulava 2004-09-14 11:24:36 +0400 Created attachment 592 Исправление последовательности запуска сервисов Прилагаемый патч решает вопрос последовательности _запуска_ сервисов hotplug, upsdrv, upsd, upsmon. Что до последовательности _останова_ - при поверхностном взгляде практической проблемы с остановом hotplug до upsmon, upsd, upsdrv я не заметил. Но логичнее, наверное, довести начатое до конца, т.е. останавливать сервисы в последовательности, противоположной запуску: upsmon, upsd, upsdrv, hotplug. 18807 2 abulava 2004-09-15 10:03:15 +0400 Мои исправления не выдержали проверки reboot'ом :-( С моими исправлениями upsdrv стартует непосредственно после hotplug, но /dev/usb/hiddev0 не успевает появиться к моменту старта сервиса upsdrv. Пока даже не предполагаю, каким способом можно _правильно_ исправить ситуацию. Для моего конкретного случая сойдёт первый попавшийся костыль, но и тут ничего кроме банального sleep пока в голову не приходит. 18978 3 ldv 2004-09-30 20:39:19 +0400 *** Bug 5162 has been marked as a duplicate of this bug. *** 18979 4 ldv 2004-09-30 20:43:02 +0400 Я склоняюсь к тому, что надо что-то делать с hotplug. Может, запускать его раньше, может, ещё что-то делать. 19412 5 vsu 2004-10-25 17:08:31 +0400 А бесполезно с ним что-то делать - время, через которое появится USB-устройство, в общем случае не ограничено (например, при наличии нескольких USB-устройств распознавание их производится процессом khubd последовательно). Разве что запускать upsdrv из hotplug. Привязка к конкретным /dev/usb/* тоже никуда не годится - номера устройств плавают (в частности, даже при наличии только одного устройства при отключении и быстром подключении устройства для него может быть выделен новый номер, если программа недостаточно быстро закроет старый файл устройства). В 2.6 эту проблему может решить udev; в 2.4 с этим хуже. 26317 6 abulava 2005-06-23 19:01:34 +0400 *** Bug 7186 has been marked as a duplicate of this bug. *** 26400 7 mike 2005-06-24 18:52:07 +0400 так... следующий блок бесперебойного пищания надо покупать с USB. 27410 8 rider 2005-07-19 12:41:33 +0400 reassign to nut-driver Необходимо переделать алгоритм запуска сервиса upsdrv для ядра 2.6 В ядре 2.6 такой сервис должен запускаться из /etc/dev.d/DEVNAME/, где DEVNAME - соответствующее устройство, создаваемое при загрузке модуля для UPS. Там же он должен и останавливаться. К сожалению у меня нет UPS, соответственно патчи сделать не могу ;-( 27736 9 dubrsl 2005-07-26 14:02:16 +0400 Могу только добавить, что данная проблема присутствует не только с USB, но и с /dev/ttyS0 при использовании udev_static-addon-0.1-alt1 и udev-0.63-alt2 30189 10 lav 2005-09-06 23:18:18 +0400 Предлагаю хотя бы перенести запуск upsd на несколько шагов позже hotplug, может хоть с /dev/ttyS? начнёт работать. Всё лучше, чем ничего. 30190 11 ldv 2005-09-07 00:42:28 +0400 Согласно комментарию #5, не начнёт. 30193 12 lav 2005-09-07 01:01:34 +0400 Ну там речь о USB, а я о /dev/ttyS? 30194 13 ldv 2005-09-07 01:08:43 +0400 А откуда проблемы с /dev/ttyS? Если из-за недонастроенного udev'а, то это не здесь надо править. 30226 14 rider 2005-09-07 15:24:51 +0400 udev тут не при чем. модуль 8250 для серийного порта грузится hotplug'ом. В приниципе скорее всего он загрузится, если попытаться открыть устройство в простом /dev/ 30232 15 ldv 2005-09-07 17:13:45 +0400 Короче говоря, файл устройства и драйвер для него могут появится когда угодно или не появится вообще, и демон (в данном случае nut'овские драйвера) тут ничего сделать не может кроме как надеятся что файл устройства работает. 30233 16 rider 2005-09-07 17:16:44 +0400 Да. Но здесь есть возможность запускать nut тогда, когда собственно появляется само устройство. Т.е. - убрать из сервисов и переместить запуск в udev udev дает возможность запускать любые приложения при появлении/удалении устройств 30239 17 lav 2005-09-07 18:26:55 +0400 (In reply to comment #15) > Короче говоря, файл устройства и драйвер для него могут появится когда Я предлагаю передвинуть upsdrv/upsd и поставить после postfix (а то он ещё и письма слать не может при ошибке инициализации). Хуюе от этого вряд ли будет, а автору баги и мне, например, полегче. 30245 18 abulava 2005-09-07 18:46:53 +0400 (In reply to comment #17) > Я предлагаю передвинуть upsdrv/upsd и поставить после postfix (а то он ещё и > письма слать не может при ошибке инициализации). > Хуже от этого вряд ли будет, а автору баги и мне, например, полегче. Всегда найдётся человек, у которого upsdrv стартует быстрее, чем будет распознан USB UPS :-( BTW, в силу нетерпимости upsd к отсутствию upsdrv (иными словами, upsd сразу же вылетает с ошибкой, если на момент старта upsd не найдёт запущенного upsdrv), из udev придётся запускать сначала upsdrv, а затем upsd. Так что сервисом останется только upsmon :-| 31651 19 ldv 2005-10-10 21:07:08 +0400 * 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). 31653 20 ldv 2005-10-10 21:08:07 +0400 *** Bug 6329 has been marked as a duplicate of this bug. *** 36893 21 rider 2006-03-20 19:50:21 +0300 ссылка весьма интересна. На мой взгляд стоит подождать, пока это пропихнут в upstream. Но на серверах такую схему я бы поостерёгся использовать.. или нам нужно думать, как разделить права на запуск утилиты управления питанием (например powersaved) 57953 22 mike 2007-11-10 21:10:47 +0300 (In reply to comment #9) > Могу только добавить, что данная проблема присутствует не только с USB, но и с > /dev/ttyS0 при использовании udev_static-addon-0.1-alt1 и udev-0.63-alt2 А вот если /dev/ttyS0 положить в "железный" /dev, прям на rootfs -- тогда работаем. Кажется, я про это отдельный баг вешал. 65280 23 mike 2008-03-07 20:41:46 +0300 Кстати, для такого "положить" давно собирался сделать dev-minimal (тж. #12020). 99337 24 ldv 2009-09-18 01:11:22 +0400 Пакет nut ищет мейнтейнера. 116759 25 mike 2010-12-29 13:17:51 +0300 Пакет сборки amike@ залил в сизиф всё-таки я. 131049 26 mike 2012-05-05 23:12:01 +0400 Просьба проверить на 2.6.x, если ещё представляется возможным; УМВР. 592 2004-09-14 11:24:36 +0400 2004-09-14 11:24:36 +0400 Исправление последовательности запуска сервисов nut-startup-seq.patch text/plain 788 abulava LS0tIGluaXQuZC91cHNkLm51dC1zdGFydHVwLXNlcQkyMDA0LTAzLTE1IDE4OjQ0OjU4ICswMjAw CisrKyBpbml0LmQvdXBzZAkyMDA0LTA5LTE0IDA5OjQwOjEyICswMzAwCkBAIC0xLDYgKzEsNiBA QAogIyEvYmluL3NoCiAjCi0jIGNoa2NvbmZpZzogMjM0NSAzMSA4OAorIyBjaGtjb25maWc6IDIz NDUgMzQgODgKICMgZGVzY3JpcHRpb246IFRoZSBVUFMgaW5mb3JtYXRpb24gc2VydmVyCiAjIHBy b2Nlc3NuYW1lOiB1cHNkCiAjIGNvbmZpZzogL2V0Yy91cHMvCi0tLSBpbml0LmQvdXBzZHJ2Lm51 dC1zdGFydHVwLXNlcQkyMDA0LTA5LTE0IDA5OjM4OjAyICswMzAwCisrKyBpbml0LmQvdXBzZHJ2 CTIwMDQtMDktMTQgMDk6Mzc6MzAgKzAzMDAKQEAgLTEsNiArMSw2IEBACiAjIS9iaW4vc2gKICMK LSMgY2hrY29uZmlnOiAyMzQ1IDMwIDg5CisjIGNoa2NvbmZpZzogMjM0NSAzMyA4OQogIyBkZXNj cmlwdGlvbjogVGhlIFVQUyBkcml2ZXJzCiAjIGNvbmZpZzogL2V0Yy91cHMvCiAKLS0tIGluaXQu ZC91cHNtb24ubnV0LXN0YXJ0dXAtc2VxCTIwMDQtMDMtMTUgMTg6NDQ6NDYgKzAyMDAKKysrIGlu aXQuZC91cHNtb24JMjAwNC0wOS0xNCAwOTo0MDozNyArMDMwMApAQCAtMSw2ICsxLDYgQEAKICMh L2Jpbi9zaAogIwotIyBjaGtjb25maWc6IDIzNDUgMzIgODcKKyMgY2hrY29uZmlnOiAyMzQ1IDM1 IDg3CiAjIGRlc2NyaXB0aW9uOiBUaGUgVVBTIG1vbml0b3IgYW5kIHNodXRkb3duIGNvbnRyb2xs ZXIKICMgcHJvY2Vzc25hbWU6IHVwc21vbgogIyBjb25maWc6IC9ldGMvdXBzLwo=