#28038 – collectd: Необходимо обеспечить совместимость службы с systemd

Bug 28038 - collectd: Необходимо обеспечить совместимость службы с systemd

Summary: collectd: Необходимо обеспечить совместимость службы с systemd

Status:	CLOSED FIXED

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	collectd (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 normal
Assignee:	Anton Farygin
QA Contact:	qa-sisyphus

URL:	http://www.altlinux.org/Systemd_Statu...
Keywords:

Depends on:
Blocks:	28008 30879
	Show dependency tree

Reported:	2012-11-21 15:36 MSK by Mike
Modified:	2015-03-30 12:25 MSK (History)
CC List:	14 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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

Description

Mike 2012-11-21 15:36:26 MSK

Необходимо обеспечить совместимость службы с systemd
Подготовить корректный unit-файл.

Подробности по ссылке: http://www.altlinux.org/Systemd_Status_P7

Comment 1

Michael Shigorin 2012-11-21 17:04:19 MSK

Или кто другой, или после EFI и прочего более важного.
systemd неинтересен.

Comment 2

Alexey Shabalin 2014-09-16 21:34:58 MSK

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

Comment 3

viy 2014-09-16 22:03:37 MSK

странно, почему баг на nobody?

Comment 4

Vitaly Lipatov 2015-01-13 15:37:09 MSK

Надо обсудить: сейчас в init-скрипте запускается collectdmon, который следит (достаточно неудачно) за процессом collectd.
Предлагаю от него избавиться, и запускать сразу процесс collectd.
С задачей перезапуска справится systemd. А для скриптов systemV можно дописать правило для monit.

Comment 5

Sergey Y. Afonin 2015-01-13 15:51:29 MSK

Я правильно понимаю, что unit-файл избавляет от необходимости использовать init-скрипт, и там можно сделать без collectdmon ? Если да, надо так делать, а по поводу избавления от collectdmon в sysvinit завети отдельный баг и там обсудить.

Comment 6

Michael Shigorin 2015-01-13 16:36:24 MSK

(В ответ на комментарий №5)
> Я правильно понимаю, что unit-файл избавляет от необходимости использовать
> init-скрипт, и там можно сделать без collectdmon ?
Там-то явно избыточно.

> Если да, надо так делать, а по поводу избавления от collectdmon в sysvinit
> завети отдельный баг и там обсудить.
Если не изменяет склероз, то изначально collectd я паковал без использования collectdmon и достаточно вернуться к этому.

(В ответ на комментарий №4)
> А для скриптов systemV можно дописать правило для monit.
Собственно, можно его сразу и паковать, добавив зависимость на monit-base (что не приведёт к установке самого monit, но в случае установки сделает конфигурирование максимально быстрым).  Второй вариант -- добавить в примеры из комплекта monit.

Вот это точно отдельный баг (FR), над которым думаю со времён Server 4.0 и никак не решусь махнуть шашкой.

Comment 7

Anton Farygin 2015-01-13 16:41:53 MSK

не надо ещё monit тащить. Можно для systemd запаковать правильный сервис-файл, а под initscript гораздо удобнее запускать под collectdmon.

Я его втащил, т.к. столкнулся с падениями collectd и лучше без дополнительных зависимостей.

Comment 8

Vitaly Lipatov 2015-01-13 18:43:59 MSK

(В ответ на комментарий №7)
> Я его втащил, т.к. столкнулся с падениями collectd и лучше без дополнительных
> зависимостей.
Спасибо, но сейчас у нас
а) collectd жутко течёт
б) не прибивается через /etc/init.d/collecd stop (порождённый процесс collectd -f не завершается)
в) когда каждая программа начинает сама следить за собой, да ещё и неумело, получается ужасный зоопарк.

Я уже понял, что сбежать получится только в systemd. Как бы ни хотелось.

Comment 9

Anton Farygin 2015-01-13 18:45:19 MSK

Виталь, а где у тебя collectd жутко течёт ?

У меня collectd из Sisyphus работает месяцами без проблем.
Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек ?

Comment 10

Michael Shigorin 2015-01-13 19:38:58 MSK

(В ответ на комментарий №8)
> Я уже понял, что сбежать получится только в systemd. Как бы ни хотелось.
Ну, такой подход гарантирует только дальнейшее понижение качества софта.
Не приемлю.

Comment 11

Anton Farygin 2015-01-13 21:32:59 MSK

Для повышения качества софта надо найти исправить в нём ошибки.

Но у меня оно не воспроизводится, а у вас ?

Comment 12

Vitaly Lipatov 2015-01-14 14:39:27 MSK

(В ответ на комментарий №9)
> Виталь, а где у тебя collectd жутко течёт ?
> 
> У меня collectd из Sisyphus работает месяцами без проблем.
> Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек
Если можно обновить в p7 до Сизифного — отлично. Если надо, можно сделать task, я готов потестировать перед тем, как его примут в p7.

Путём исключения выяснили, что нужен настроенный
LoadPlugin mysql
чтобы началась утечка. Возможно, его просто никто не использует :)

Comment 13

Anton Farygin 2015-01-14 15:07:21 MSK

Для серьёзных задач (где MySQL) есть Zabbix.

Comment 14

Andrey Cherepanov 2015-01-14 15:56:24 MSK

(В ответ на комментарий №12)
> (В ответ на комментарий №9)
> > Виталь, а где у тебя collectd жутко течёт ?
> > 
> > У меня collectd из Sisyphus работает месяцами без проблем.
> > Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек
> Если можно обновить в p7 до Сизифного — отлично. Если надо, можно сделать task,
> я готов потестировать перед тем, как его примут в p7.
Сделай, пожалуйста.

Comment 15

Vitaly Lipatov 2015-01-14 19:56:29 MSK

(В ответ на комментарий №14)
> (В ответ на комментарий №12)
> > (В ответ на комментарий №9)
> > > Виталь, а где у тебя collectd жутко течёт ?
...
> > я готов потестировать перед тем, как его примут в p7.
> Сделай, пожалуйста.
Собрал под p7, проверил, течь перестало:
[#138515] p7 EPERM collectd.git=5.4.1-alt1.M70P.2.1
Думаю, аппрувить пока не надо, подождём добавления .service для systemd в сбоку для Сизифа?

Comment 16

Michael Shigorin 2015-01-15 13:35:41 MSK

(В ответ на комментарий №13)
> Для серьёзных задач (где MySQL) есть Zabbix.
Он умеет мониторить mysql, а не складывать в него? :)

Comment 17

Michael Shigorin 2015-01-15 13:36:40 MSK

https://collectd.org/wiki/index.php/Plugin:MySQL

Comment 18

Sergey Y. Afonin 2015-01-16 10:26:28 MSK

(In reply to comment #12)

> Путём исключения выяснили, что нужен настроенный
> LoadPlugin mysql
> чтобы началась утечка.

Не только. Я смотрел 5.4.1 в прошлом году, вот тут кое-что написано:
http://lists.altlinux.org/pipermail/sysadmins/2014-June/036828.html

В итоге, я откатился на 5.2.1 после того эксперимента. Сейчас попробую обновиться из задания 138515.

Comment 19

Sergey Y. Afonin 2015-01-16 10:32:26 MSK

(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.

Comment 20

Sergey Y. Afonin 2015-01-21 08:46:42 MSK

(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 не течёт в таком же режиме работы.

Comment 21

Vitaly Lipatov 2015-01-21 12:54:08 MSK

(В ответ на комментарий №20)
...
> Течёт:
Я был не прав, начав обсуждать проблемы collectd в этой баге. Давайте про «течёт» заведём тогда отдельную багу, и в ней исследовать, какой именно плагин течёт...

Comment 22

Sergey Y. Afonin 2015-01-22 09:32:16 MSK

(In reply to comment #21)

> Давайте про «течёт» заведём тогда отдельную багу

bug #30668

Comment 23

Anton Farygin 2015-01-26 18:34:45 MSK

Да, Zabbix'ом можно мониторить MySQL И всё что хочется.
http://wiki.enchtex.info/howto/zabbix/advanced_mysql_monitoring

Что касается утечек - Виталь, опиши плз, воспроизводится ли у тебя проблема с утечкой ?

Что касается  collectd поддержки systemd - скоро будет.

Comment 24

Vitaly Lipatov 2015-01-26 19:09:38 MSK

(В ответ на комментарий №23)
...
> Что касается утечек - Виталь, опиши плз, воспроизводится ли у тебя проблема с
> утечкой ?
После обновление до сизифной 5.4.1 у меня проблема ушла.

Comment 25

Anton Farygin 2015-01-26 20:29:03 MSK

И перезапускается нормально ?

Comment 26

Vitaly Lipatov 2015-01-26 21:32:32 MSK

(В ответ на комментарий №25)
> И перезапускается нормально ?
Да

Comment 27

Repository Robot 2015-01-27 14:59:17 MSK

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)