J'ai une version fraîchement installée sur CentOS 7 une fois que je l'ai installé syslog-ng à partir des dépôts de EPEL.
~: yum list | grep syslog
syslog-ng.x86_64 3.5.6-1.el7 @epel
Lorsque je tente de le lancer via systemctl, il échoue comme suit:
/usr/lib/systemd/system: systemctl start syslog-ng
Job for syslog-ng.service failed. See 'systemctl status syslog-ng.service' and 'journalctl -xn' for details.
Comme indiqué ci-dessous quand on regarde dans les journaux, nous pouvons voir que leur est une dépendance à la prise qui " commence ", mais bien que le processus renvoie une erreur sur les arguments étant incorrect:
May 07 17:26:15 superserver.company.corp systemd[1]: Starting Syslog Socket.
May 07 17:26:15 superserver.company.corp systemd[1]: Listening on Syslog Socket.
May 07 17:26:15 superserver.company.corp systemd[1]: Starting System Logger Daemon...
May 07 17:26:15 superserver.company.corp systemd[1]: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
May 07 17:26:15 superserver.company.corp systemd[1]: Failed to start System Logger Daemon.
May 07 17:26:15 superserver.company.corp systemd[1]: Unit syslog-ng.service entered failed state.
May 07 17:26:15 superserver.company.corp systemd[1]: syslog-ng.service holdoff time over, scheduling restart.
May 07 17:26:15 superserver.company.corp systemd[1]: Stopping System Logger Daemon...
May 07 17:26:15 superserver.company.corp systemd[1]: Starting System Logger Daemon...
May 07 17:26:15 superserver.company.corp systemd[1]: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Si l'on regarde dans le fichier de configuration de service, nous pouvons confirmer la dépendance à la prise et la commande qui est utilisée pour démarrer le service.
[Service]
Type=notify
Sockets=syslog.socket
ExecStart=/usr/sbin/syslog-ng -F -p /var/run/syslogd.pid
Le problème est que si je lance la commande ci-dessus mentionné, il démarre très bien et cela fonctionne comme prévu.
Ma question est: quelle est la différence entre moi en cours d'exécution de la commande de démarrage du programme et systemd démarrage le même programme? Que puis-je faire pour savoir ce qui est réellement le problème?
Edit 1
J'ai activé la sortie de débogage tel que suggéré par Raymond dans les réponses et la sortie ne nous apprend pas beaucoup plus.
May 08 10:31:29 server.corp systemd[1]: Starting System Logger Daemon...
May 08 10:31:29 server.corp systemd[1]: About to execute: /usr/sbin/syslog-ng -F -p /var/run/syslogd.pid
May 08 10:31:29 server.corp systemd[1]: Forked /usr/sbin/syslog-ng as 3121
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service changed dead -> start
May 08 10:31:29 server.corp systemd[1]: Set up jobs progress timerfd.
May 08 10:31:29 server.corp systemd[1]: Set up idle_pipe watch.
May 08 10:31:29 server.corp systemd[3121]: Executing: /usr/sbin/syslog-ng -F -p /var/run/syslogd.pid
May 08 10:31:29 server.corp systemd[1]: Got notification message for unit syslog-ng.service
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service: Got message
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service: got STATUS=Starting up... (Fri May 8 10:31:29 2015
May 08 10:31:29 server.corp systemd[1]: Got notification message for unit syslog-ng.service
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service: Got message
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service: got STATUS=Starting up... (Fri May 8 10:31:29 2015
May 08 10:31:29 server.corp systemd[1]: Received SIGCHLD from PID 3121 (syslog-ng).
May 08 10:31:29 server.corp systemd[1]: Child 3121 (syslog-ng) died (code=exited, status=2/INVALIDARGUMENT)
May 08 10:31:29 server.corp systemd[1]: Child 3121 belongs to syslog-ng.service
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
May 08 10:31:29 server.corp systemd[1]: syslog-ng.service changed start -> failed
May 08 10:31:29 server.corp systemd[1]: Job syslog-ng.service/start finished, result=failed
May 08 10:31:29 server.corp systemd[1]: Failed to start System Logger Daemon.
Il y a quelques avertissements qui apparaissent au début des processus de syslog-ng (rien qui l'empêche de démarrer correctement) donc je réorienté toutes les sorties vers/dev/null, mais le résultat final est le même.
En outre, comme une note de côté, tout mon système ne démarre plus si systemd est incapable de syslog. Ceci peut être désactivé avec des options du noyau pour se connecter à kmesg.
Nous avons eu le même problème sur Debian 8.1, mais la corrigée en modifiant notre configuration locale SysLog-NG pour utiliser unix-dgram
à la place de unix-socket
.
J'ai été signalé par ce commentaire à Redhat Bugzilla :
Remarque sur les fichiers de configurations SysLog-NG personnalisés
Les personnes avec des configurations de SysLog-NG personnalisées seront probablement confrontées à des problèmes de mise à niveau en raison de l'inadéquation de type Socket Unix entre SystemD et SysLog-NG File de configuration ancienne:
- systemD crée/dev/loger comme
unix-dgram
- syslog-ng <3.2.5 attendu/dev/journal pour être
unix-stream
(fichier de configuration)Si vous utilisez 'Unix-Stream ("/ dev/log")' dans l'une de vos sources de messages de journal, vous devrez le modifier manuellement sur 'Unix-dgram ("/ dev/log")'.
fixé en ajoutant ceci à Syslog-ng.service: After = Network.Target
https://bugzilla.redhat.com/show_bug.cgi?id=1309345
# cat /usr/lib/systemd/system/syslog-ng.service
[Unit]
Description=System Logger Daemon
Documentation=man:syslog-ng(8)
After=network.target
[Service]
Type=notify
Sockets=syslog.socket
ExecStart=/usr/sbin/syslog-ng -F -p /var/run/syslogd.pid
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=syslog.service
Peut-être essayer d'ajouter:
Environment=SYSTEMD_LOG_LEVEL=debug
Au fichier de votre unité de service, puis voyez ce qui décharge?
Je me demande également si SystemD tente de veiller à ce que Syslog-NG a commencé avec succès en exécutant un
systemctl status syslog-ng
et car il n'y a pas de directive "Status" correspondante dans votre fichier de l'unité, il suppose que le service n'a pas été démarré correctement et tue le processus?