Je n'arrive pas à baisser l'intensité des logs d'icinga2 dans
/var/log/syslog.
J'ai tenté de passer par /etc/default/icinga2 en rajoutant -x critical
comme l'indique la doc :
[root@canoe]:~ # cat /etc/default/icinga2
# default settings for icinga2's initscript
DAEMON_ARGS="-d -e /var/log/icinga2/icinga2.err -x critical"
Je suis aussi passé directement par le script /etc/init.d/icinga2 en
modifiant DAEMON_ARGS:
DAEMON_ARGS="-e /var/log/icinga2/icinga2.err -x critical"
Mais rien à faire, après un
service icinga2 restart, ps -axuf m'indique toujours :
nagios 13129 6.3 2.8 939920 25648 ? Ssl 13:19 0:00
/usr/lib/x86_64-linux-gnu/icinga2/sbin/icinga2 --no-stack-rlimit daemon
-e /var/log/icinga2/error.log
nagios 13169 0.0 0.1 511768 1256 ? S 13:19 0:00 \_
/usr/lib/x86_64-linux-gnu/icinga2/sbin/icinga2 --no-stack-rlimit daemon
-e /var/log/icinga2/error.log
Donc aucun des arguments passés... Est-ce normal ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel Caillibaud
Le 16/04/19 à 16:47, Migrec a écrit :
Bonjour, Je n'arrive pas à baisser l'intensité des logs d'icinga2 dans /var/log/syslog. J'ai tenté de passer par /etc/default/icinga2 en rajoutant -x critic al Je suis aussi passé directement par le script /etc/init.d/icinga2 en Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition dans /etc/systemd/system (dans ce cas /etc/default et /etc/init.d/tonService sont ignorés) Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu dois créer un fichier /etc/systemd/system/icinga2.service.d/override.c onf (le nom "override" est arbitraire mais il faut l'extension .conf) qui contiendrait par ex [Unit] Description=version perso du service icinga2 (moins verbeuse) [Service] # il faut affecter un truc vide avant une nouvelle valeur, # sinon ça râle avec # Service has more than one ExecStart= setting … ExecStart= # et ta commande de démarrage ExecStart=commande du service d'origine avec tes options Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais c'est pas conseillé, en général c'est un lien vers du /lib/s ystemd/system/… fourni par le paquet qu'il vaut mieux laisser intact (ne serait-ce que pour s'y référer). Tu pourrais aussi supprimer le lien et remplacer ça par un fichier de ton cru, mais l'avantage de la surcharge dans le dossier *.d est de ne modifier que ce qui t'intéresse et suivre les évolutions du paque t pour le reste. -- Daniel (A Darwin qui lui expliquait que l'homme descendait du singe) "Mon Dieu, pourvu que cela ne se sache pas!" La reine Victoria.
Le 16/04/19 à 16:47, Migrec <mic.grentz@online.fr> a écrit :
Bonjour,
Je n'arrive pas à baisser l'intensité des logs d'icinga2 dans
/var/log/syslog.
J'ai tenté de passer par /etc/default/icinga2 en rajoutant -x critic al
Je suis aussi passé directement par le script /etc/init.d/icinga2 en
Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition
dans /etc/systemd/system (dans ce cas /etc/default
et /etc/init.d/tonService sont ignorés)
Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu
dois créer un fichier /etc/systemd/system/icinga2.service.d/override.c onf
(le nom "override" est arbitraire mais il faut l'extension .conf) qui
contiendrait par ex
[Unit]
Description=version perso du service icinga2 (moins verbeuse)
[Service]
# il faut affecter un truc vide avant une nouvelle valeur,
# sinon ça râle avec
# Service has more than one ExecStart= setting …
ExecStart=
# et ta commande de démarrage
ExecStart=commande du service d'origine avec tes options
Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais
c'est pas conseillé, en général c'est un lien vers du /lib/s ystemd/system/…
fourni par le paquet qu'il vaut mieux laisser intact (ne serait-ce que pour
s'y référer).
Tu pourrais aussi supprimer le lien et remplacer ça par un fichier de ton
cru, mais l'avantage de la surcharge dans le dossier *.d est de ne
modifier que ce qui t'intéresse et suivre les évolutions du paque t pour le
reste.
--
Daniel
(A Darwin qui lui expliquait que l'homme descendait du singe)
"Mon Dieu, pourvu que cela ne se sache pas!"
La reine Victoria.
Bonjour, Je n'arrive pas à baisser l'intensité des logs d'icinga2 dans /var/log/syslog. J'ai tenté de passer par /etc/default/icinga2 en rajoutant -x critic al Je suis aussi passé directement par le script /etc/init.d/icinga2 en Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition dans /etc/systemd/system (dans ce cas /etc/default et /etc/init.d/tonService sont ignorés) Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu dois créer un fichier /etc/systemd/system/icinga2.service.d/override.c onf (le nom "override" est arbitraire mais il faut l'extension .conf) qui contiendrait par ex [Unit] Description=version perso du service icinga2 (moins verbeuse) [Service] # il faut affecter un truc vide avant une nouvelle valeur, # sinon ça râle avec # Service has more than one ExecStart= setting … ExecStart= # et ta commande de démarrage ExecStart=commande du service d'origine avec tes options Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais c'est pas conseillé, en général c'est un lien vers du /lib/s ystemd/system/… fourni par le paquet qu'il vaut mieux laisser intact (ne serait-ce que pour s'y référer). Tu pourrais aussi supprimer le lien et remplacer ça par un fichier de ton cru, mais l'avantage de la surcharge dans le dossier *.d est de ne modifier que ce qui t'intéresse et suivre les évolutions du paque t pour le reste. -- Daniel (A Darwin qui lui expliquait que l'homme descendait du singe) "Mon Dieu, pourvu que cela ne se sache pas!" La reine Victoria.
Migrec
Le 16/04/2019 à 17:23, Daniel Caillibaud a écrit :
Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition dans /etc/systemd/system (dans ce cas /etc/default et /etc/init.d/tonService sont ignorés) Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu dois créer un fichier /etc/systemd/system/icinga2.service.d/override.conf (le nom "override" est arbitraire mais il faut l'extension .conf) qui contiendrait par ex [Unit] Description=version perso du service icinga2 (moins verbeuse) [Service] # il faut affecter un truc vide avant une nouvelle valeur, # sinon ça râle avec # Service has more than one ExecStart= setting … ExecStart > # et ta commande de démarrage ExecStart=commande du service d'origine avec tes options Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais
Bonjour, Parfait ! Je n'ai plus du tout pensé que c'était systemd qui gérait ça maintenant, mon serveur est à jour mais je l'oublie un peu tellement il fonctionne "bien". Donc j'ai du farfouiller un peu car le script est dans /etc/systemd/system/multi-user.target.wants. J'ai du mal à comprendre l'imbrication de tout ça mais je viens de trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent plus du tout ? Les logs sont désormais plus lisibles ! Merci. -- Migrec
Le 16/04/2019 à 17:23, Daniel Caillibaud a écrit :
Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition
dans /etc/systemd/system (dans ce cas /etc/default
et /etc/init.d/tonService sont ignorés)
Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu
dois créer un fichier /etc/systemd/system/icinga2.service.d/override.conf
(le nom "override" est arbitraire mais il faut l'extension .conf) qui
contiendrait par ex
[Unit]
Description=version perso du service icinga2 (moins verbeuse)
[Service]
# il faut affecter un truc vide avant une nouvelle valeur,
# sinon ça râle avec
# Service has more than one ExecStart= setting …
ExecStart > # et ta commande de démarrage
ExecStart=commande du service d'origine avec tes options
Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais
Bonjour,
Parfait ! Je n'ai plus du tout pensé que c'était systemd qui gérait ça
maintenant, mon serveur est à jour mais je l'oublie un peu tellement il
fonctionne "bien".
Donc j'ai du farfouiller un peu car le script est dans
/etc/systemd/system/multi-user.target.wants.
J'ai du mal à comprendre l'imbrication de tout ça mais je viens de
trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent
plus du tout ?
Le 16/04/2019 à 17:23, Daniel Caillibaud a écrit :
Donc aucun des arguments passés... Est-ce normal ?
Oui si tu utilises systemd et que icinga2 a une définition dans /etc/systemd/system (dans ce cas /etc/default et /etc/init.d/tonService sont ignorés) Dans ce cas (ton système utilise /etc/systemd/system/icinga2.service) tu dois créer un fichier /etc/systemd/system/icinga2.service.d/override.conf (le nom "override" est arbitraire mais il faut l'extension .conf) qui contiendrait par ex [Unit] Description=version perso du service icinga2 (moins verbeuse) [Service] # il faut affecter un truc vide avant une nouvelle valeur, # sinon ça râle avec # Service has more than one ExecStart= setting … ExecStart > # et ta commande de démarrage ExecStart=commande du service d'origine avec tes options Tu pourrais modifier directement /etc/systemd/system/icinga2.service mais
Bonjour, Parfait ! Je n'ai plus du tout pensé que c'était systemd qui gérait ça maintenant, mon serveur est à jour mais je l'oublie un peu tellement il fonctionne "bien". Donc j'ai du farfouiller un peu car le script est dans /etc/systemd/system/multi-user.target.wants. J'ai du mal à comprendre l'imbrication de tout ça mais je viens de trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent plus du tout ? Les logs sont désormais plus lisibles ! Merci. -- Migrec
Daniel Caillibaud
Le 16/04/19 à 21:56, Migrec a écrit :
Donc j'ai du farfouiller un peu car le script est dans /etc/systemd/system/multi-user.target.wants.
Ah oui, dsl, parfois le script est dans /etc/systemd/system/leService.servi ce et il est activé par un symlink /etc/systemd/system/multi-user.target.wants/leService.service -> ../leSer vice.service et parfois c'est directement un symlink de multi-user.target.wants (ou une autre dépendance) vers /lib/systemd/system Ce lien est créé ou supprimé par systemctl enable|disable le Service
J'ai du mal à comprendre l'imbrication de tout ça mais je viens de trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent plus du tout ?
Ça dépend ;-) Si tu as le paquet systemd-sysv, systemd va gérer les services qui n'e xistent pas dans /etc/systemd/ mais qui ont un fichier dans /etc/init.d à trav ers ce dernier. Si tu n'as pas ce paquet, /etc/init.d est complètement ignoré. Pour /etc/default je sais pas, à priori c'est plutôt pour sysv ma is rien n'empêcherait un service systemd de sourcer /etc/default, je sais pas si certains le font. -- Daniel On ne peut pas tout avoir. Où le mettrait on ? Steven Wright
Le 16/04/19 à 21:56, Migrec <mic.grentz@online.fr> a écrit :
Donc j'ai du farfouiller un peu car le script est dans
/etc/systemd/system/multi-user.target.wants.
Ah oui, dsl, parfois le script est dans /etc/systemd/system/leService.servi ce
et il est activé par un symlink
/etc/systemd/system/multi-user.target.wants/leService.service -> ../leSer vice.service
et parfois c'est directement un symlink de multi-user.target.wants (ou une autre dépendance)
vers /lib/systemd/system
Ce lien est créé ou supprimé par systemctl enable|disable le Service
J'ai du mal à comprendre l'imbrication de tout ça mais je viens de
trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent
plus du tout ?
Ça dépend ;-)
Si tu as le paquet systemd-sysv, systemd va gérer les services qui n'e xistent
pas dans /etc/systemd/ mais qui ont un fichier dans /etc/init.d à trav ers ce dernier.
Si tu n'as pas ce paquet, /etc/init.d est complètement ignoré.
Pour /etc/default je sais pas, à priori c'est plutôt pour sysv ma is rien n'empêcherait un
service systemd de sourcer /etc/default, je sais pas si certains le font.
--
Daniel
On ne peut pas tout avoir. Où le mettrait on ?
Steven Wright
Donc j'ai du farfouiller un peu car le script est dans /etc/systemd/system/multi-user.target.wants.
Ah oui, dsl, parfois le script est dans /etc/systemd/system/leService.servi ce et il est activé par un symlink /etc/systemd/system/multi-user.target.wants/leService.service -> ../leSer vice.service et parfois c'est directement un symlink de multi-user.target.wants (ou une autre dépendance) vers /lib/systemd/system Ce lien est créé ou supprimé par systemctl enable|disable le Service
J'ai du mal à comprendre l'imbrication de tout ça mais je viens de trouver l'occasion de comprendre. Les scripts /etc/init.d/ ne servent plus du tout ?
Ça dépend ;-) Si tu as le paquet systemd-sysv, systemd va gérer les services qui n'e xistent pas dans /etc/systemd/ mais qui ont un fichier dans /etc/init.d à trav ers ce dernier. Si tu n'as pas ce paquet, /etc/init.d est complètement ignoré. Pour /etc/default je sais pas, à priori c'est plutôt pour sysv ma is rien n'empêcherait un service systemd de sourcer /etc/default, je sais pas si certains le font. -- Daniel On ne peut pas tout avoir. Où le mettrait on ? Steven Wright
