Summary: | collectd: Необходимо обеспечить совместимость службы с systemd | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Mike <amike> |
Component: | collectd | Assignee: | Anton Farygin <rider> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | anton, asy, at, cas, crux, danil, ender, lav, ldv, mike, qa_viy, rider, shaba, viy |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
URL: | http://www.altlinux.org/Systemd_Status_P7 | ||
Bug Depends on: | |||
Bug Blocks: | 28008, 30879 |
Description
Mike
2012-11-21 15:36:26 MSK
Или кто другой, или после EFI и прочего более важного. systemd неинтересен. unit-файл collectd.service уже есть в исходниках, в contrib/ Его надо только упаковать в %_unitdir/collectd.service И еще в collectd.init не соответствуют: # config: /etc/default/collectd # pidfile: /var/run/collectd.pid и PIDFILE=/var/run/collectdmon.pid если запускать с помощью systemd, то это критично. еще бы хорошо добавить LSB заголовок ### BEGIN INIT INFO # Provides: collectd # Required-Start: $local_fs $network # Required-Stop: $local_fs $network # Default-Start: 3 4 5 # Default-Stop: 0 1 2 6 # Short-Description: Statistics daemon collectd # Description: Start the statistics daemon collectd ### END INIT INFO странно, почему баг на nobody? Надо обсудить: сейчас в init-скрипте запускается collectdmon, который следит (достаточно неудачно) за процессом collectd. Предлагаю от него избавиться, и запускать сразу процесс collectd. С задачей перезапуска справится systemd. А для скриптов systemV можно дописать правило для monit. Я правильно понимаю, что unit-файл избавляет от необходимости использовать init-скрипт, и там можно сделать без collectdmon ? Если да, надо так делать, а по поводу избавления от collectdmon в sysvinit завети отдельный баг и там обсудить. (В ответ на комментарий №5) > Я правильно понимаю, что unit-файл избавляет от необходимости использовать > init-скрипт, и там можно сделать без collectdmon ? Там-то явно избыточно. > Если да, надо так делать, а по поводу избавления от collectdmon в sysvinit > завети отдельный баг и там обсудить. Если не изменяет склероз, то изначально collectd я паковал без использования collectdmon и достаточно вернуться к этому. (В ответ на комментарий №4) > А для скриптов systemV можно дописать правило для monit. Собственно, можно его сразу и паковать, добавив зависимость на monit-base (что не приведёт к установке самого monit, но в случае установки сделает конфигурирование максимально быстрым). Второй вариант -- добавить в примеры из комплекта monit. Вот это точно отдельный баг (FR), над которым думаю со времён Server 4.0 и никак не решусь махнуть шашкой. не надо ещё monit тащить. Можно для systemd запаковать правильный сервис-файл, а под initscript гораздо удобнее запускать под collectdmon. Я его втащил, т.к. столкнулся с падениями collectd и лучше без дополнительных зависимостей. (В ответ на комментарий №7) > Я его втащил, т.к. столкнулся с падениями collectd и лучше без дополнительных > зависимостей. Спасибо, но сейчас у нас а) collectd жутко течёт б) не прибивается через /etc/init.d/collecd stop (порождённый процесс collectd -f не завершается) в) когда каждая программа начинает сама следить за собой, да ещё и неумело, получается ужасный зоопарк. Я уже понял, что сбежать получится только в systemd. Как бы ни хотелось. Виталь, а где у тебя collectd жутко течёт ? У меня collectd из Sisyphus работает месяцами без проблем. Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек ? (В ответ на комментарий №8) > Я уже понял, что сбежать получится только в systemd. Как бы ни хотелось. Ну, такой подход гарантирует только дальнейшее понижение качества софта. Не приемлю. Для повышения качества софта надо найти исправить в нём ошибки. Но у меня оно не воспроизводится, а у вас ? (В ответ на комментарий №9) > Виталь, а где у тебя collectd жутко течёт ? > > У меня collectd из Sisyphus работает месяцами без проблем. > Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек Если можно обновить в p7 до Сизифного — отлично. Если надо, можно сделать task, я готов потестировать перед тем, как его примут в p7. Путём исключения выяснили, что нужен настроенный LoadPlugin mysql чтобы началась утечка. Возможно, его просто никто не использует :) Для серьёзных задач (где MySQL) есть Zabbix. (В ответ на комментарий №12) > (В ответ на комментарий №9) > > Виталь, а где у тебя collectd жутко течёт ? > > > > У меня collectd из Sisyphus работает месяцами без проблем. > > Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек > Если можно обновить в p7 до Сизифного — отлично. Если надо, можно сделать task, > я готов потестировать перед тем, как его примут в p7. Сделай, пожалуйста. (В ответ на комментарий №14) > (В ответ на комментарий №12) > > (В ответ на комментарий №9) > > > Виталь, а где у тебя collectd жутко течёт ? ... > > я готов потестировать перед тем, как его примут в p7. > Сделай, пожалуйста. Собрал под p7, проверил, течь перестало: [#138515] p7 EPERM collectd.git=5.4.1-alt1.M70P.2.1 Думаю, аппрувить пока не надо, подождём добавления .service для systemd в сбоку для Сизифа? (В ответ на комментарий №13) > Для серьёзных задач (где MySQL) есть Zabbix. Он умеет мониторить mysql, а не складывать в него? :) (In reply to comment #12) > Путём исключения выяснили, что нужен настроенный > LoadPlugin mysql > чтобы началась утечка. Не только. Я смотрел 5.4.1 в прошлом году, вот тут кое-что написано: http://lists.altlinux.org/pipermail/sysadmins/2014-June/036828.html В итоге, я откатился на 5.2.1 после того эксперимента. Сейчас попробую обновиться из задания 138515. (In reply to comment #18) > Не только. Я смотрел 5.4.1 в прошлом году, вот тут кое-что написано: > http://lists.altlinux.org/pipermail/sysadmins/2014-June/036828.html непосредственно про "течёт" в следующем месяце: http://lists.altlinux.org/pipermail/sysadmins/2014-July/036835.html В моей конфигурации много собирается по snmp. (In reply to comment #15) > Собрал под p7, проверил, течь перестало: > [#138515] p7 EPERM collectd.git=5.4.1-alt1.M70P.2.1 Течёт: Mon Jan 19 15:35:03 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756588 114736 5404 S 5,319 0,620 3:29.69 collectd Tue Jan 20 09:34:59 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756880 712384 5404 S 2.992 3.851 125:34.02 collectd Wed Jan 21 09:36:57 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756588 1.437g 5436 S 8.976 8.144 291:34.52 collectd Используемые у меня плагины: LoadPlugin syslog LoadPlugin cpu LoadPlugin interface LoadPlugin load LoadPlugin memory LoadPlugin network LoadPlugin rrdtool LoadPlugin sensors LoadPlugin snmp LoadPlugin match_regex LoadPlugin match_value LoadPlugin match_timediff LoadPlugin target_notification LoadPlugin target_replace LoadPlugin target_set 5.2.1 не течёт в таком же режиме работы. (В ответ на комментарий №20) ... > Течёт: Я был не прав, начав обсуждать проблемы collectd в этой баге. Давайте про «течёт» заведём тогда отдельную багу, и в ней исследовать, какой именно плагин течёт... (In reply to comment #21) > Давайте про «течёт» заведём тогда отдельную багу bug #30668 Да, Zabbix'ом можно мониторить MySQL И всё что хочется. http://wiki.enchtex.info/howto/zabbix/advanced_mysql_monitoring Что касается утечек - Виталь, опиши плз, воспроизводится ли у тебя проблема с утечкой ? Что касается collectd поддержки systemd - скоро будет. (В ответ на комментарий №23) ... > Что касается утечек - Виталь, опиши плз, воспроизводится ли у тебя проблема с > утечкой ? После обновление до сизифной 5.4.1 у меня проблема ушла. И перезапускается нормально ? (В ответ на комментарий №25)
> И перезапускается нормально ?
Да
collectd-5.4.1-alt3 -> sisyphus: * Mon Jan 26 2015 Anton Farygin <rider@altlinux> 5.4.1-alt3 - add unit file for systemd (closes: #28038) |