web-dev-qa-db-fra.com

Le service Puppetserver ne parvient pas à démarrer

J'ai un CentOS vagabond VM en cours d'exécution avec ps.memory = 2048 RAM alloué. 

Lorsque j'essaie de démarrer le service puppetserver:

$ puppet --version
4.4.0
$ Sudo puppet resource service puppetserver ensure=running
Error: Could not start Service[puppetserver]: Execution of '/bin/systemctl start puppetserver' returned 1: Job for puppetserver.service failed. See 'systemctl status puppetserver.service' and 'journalctl -xn' for details.
Error: /Service[puppetserver]/ensure: change from stopped to running failed: Could not start Service[puppetserver]: Execution of '/bin/systemctl start puppetserver' returned 1: Job for puppetserver.service failed. See 'systemctl status puppetserver.service' and 'journalctl -xn' for details.
service { 'puppetserver':
  ensure => 'stopped',
}
$ journalctl -xn
No journal files were found.
$ systemctl status puppetserver.service
puppetserver.service - puppetserver Service
   Loaded: loaded (/usr/lib/systemd/system/puppetserver.service; disabled)
  Process: 4708 ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver (code=exited, status=0/SUCCESS)
 Main PID: 4709 (Java);         : 4710 (bash)
   CGroup: /system.slice/puppetserver.service
           ├─4709 /usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError=kill -9 %p -Djava.security.egd=/...
           └─control
             ├─4710 /bin/bash /opt/puppetlabs/server/apps/puppetserver/ezbake-functions.sh wait_for_app
             └─4755 sleep 1

Mon Java_ARGS de /etc/sysconfig/puppetserver:

Java_ARGS="-Xms1g -Xmx1g -XX:MaxPermSize=1g"

Comme demandé, le fichier puppetserver.service:

$ cat /usr/lib/systemd/system/puppetserver.service
[Unit]
Description=puppetserver Service
After=syslog.target network.target

[Service]
Type=simple
EnvironmentFile=/etc/sysconfig/puppetserver
User=puppet
TimeoutStartSec=120
TimeoutStopSec=60
Restart=on-failure
StartLimitBurst=5

PermissionsStartOnly=true
ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver

ExecStart=/usr/bin/Java $Java_ARGS \
          '-XX:OnOutOfMemoryError=kill -9 %%p' \
          -Djava.security.egd=/dev/urandom \
          -cp "${INSTALL_DIR}/puppet-server-release.jar" clojure.main \
          -m puppetlabs.trapperkeeper.main \
          --config "${CONFIG}" \
          -b "${BOOTSTRAP_CONFIG}" $@

KillMode=process

ExecStartPost=/bin/bash "${INSTALL_DIR}/ezbake-functions.sh" wait_for_app

SuccessExitStatus=143

StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Une tentative d'exécution de la commande ExecStartPost à la main:

$ /usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

RuntimeError: Got 2 failure(s) while initializing: File[/var/log/puppetlabs/puppetserver]: change from 0700 to 0750 failed: failed to set mode 0700 on /var/log/puppetlabs/puppetserver: Operation not permitted - No message available; File[/var/run/puppetlabs/puppetserver]: change from 0775 to 0755 failed: failed to set mode 0775 on /var/run/puppetlabs/puppetserver: Operation not permitted - No message available

Alors j'ai réessayé, mais cette fois j'ai changé quelques permissions de répertoire, mais toujours une erreur similaire (ça n'a pas de sens vu que je viens de changer de mode?):

$ Sudo chown -R vagrant:vagrant /var/run/puppetlabs/
$ Sudo chown -R vagrant:vagrant /var/log/puppetlabs/
$ Sudo chmod -R 0755 /var/run/puppetlabs/

$ /usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=1g; support was removed in 8.0
RuntimeError: Got 1 failure(s) while initializing: File[/var/run/puppetlabs/puppetserver]: change from 0775 to 0755 failed: failed to set mode 0775 on /var/run/puppetlabs/puppetserver: Operation not permitted - No message available
                use at /opt/puppetlabs/puppet/lib/Ruby/vendor_Ruby/puppet/settings.rb:1007

Quel pourrait être le problème?

javavagrantpuppet
12
lollercoaster

Etes-vous certain qu’il s’agit d’une erreur OnOutOfMemory? Je pose la question car j’ai constaté que le dernier PuppetServer inclut une version plus récente de logback, comme le montre ce message dans/var/log/messages:

Mar 18 01:56:21 puppetserver Java: Exception in thread "main" Java.lang.AbstractMethodError: ch.qos.logback.core.net.SyslogAppenderBase.createOutputStream()Lch/qos/logback/core/net/SyslogOutputStream;
Mar 18 01:56:21 puppetserver Java: at ch.qos.logback.core.net.SyslogAppenderBase.start(SyslogAppenderBase.Java:62)
Mar 18 01:56:21 puppetserver Java: at ch.qos.logback.classic.net.SyslogAppender.start(SyslogAppender.Java:48)

Si vous voyez, cela remplace "classic.net.Syslog" dans logback.xml par "core.net.Syslog"

sed -i_old -e 's/classic.net.Syslog/core.net.Syslog/' /etc/puppetlabs/puppetserver/logback.xml

Si ce n'est pas le problème, veuillez poster vos fichiers de log.

2
Jo Rhett

Vous avez fourni log comme

Avertissement serveur OpenJDK 64 bits VM: option ignorée MaxPermSize = 1g; le support a été supprimé dans 8.0

Donc, il est clair que vous utilisez jdk 8 qui a supprimé l’espace permgen. 

L'espace Permanent Generation (PermGen) a été complètement supprimé et est en quelque sorte remplacé par un nouvel espace appelé Metaspace. La suppression de PermGen a évidemment pour conséquence que les arguments JVM PermSize et MaxPermSize sont ignorés et que vous n’obtiendrez jamais un Java.lang.OutOfMemoryError: PermGen error.

  1. Donc, veuillez supprimer la portion -XX:MaxPermSize=1g de Java_ARGS de lieu /etc/sysconfig/puppetserver 

Java_ARGS = "- Xms1g -Xmx1g"

Alors 

  1. Et alors,

votre commande sera comme ci-dessous:

$ /usr/bin/Java -Xms1g -Xmx1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

ou

$ /usr/bin/Java -Xms1g -Xmx1g -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

S'il vous plaît essayez ces 2 commandes. J'espère que les deux fonctionneront avec succès. Par prudence, j'ai ajouté les deux.

N.B: Il n'est pas nécessaire de modifier l'autorisation du fichier. gardez-les comme avant d'utiliser.

Sinon, si vous ne voulez rien changer, vous pouvez rétrograder Java 8 à Java 7

Lien connexe:

  1. Suppression de PermGen dans JDK 8
  2. Avertissement de serveur Java HotSpot (TM) 64 bits VM: option ignorée MaxPermSize
  3. Java 8 XX: PERMSIZE ET XX: MAXPERMSIZE DISAPPEARING
  4. JDK 8 Jalons
  5. PEC 122: Suppression de la génération permanente
2
SkyWalker

@lollercoster, vous commencez votre service avec:

Sudo puppet resource service puppetserver ensure=running

Mais votre prochaine commande ne dit pas de quel utilisateur il s'agit.

/usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

Veuillez exécuter whoami directement avant votre exécution de la commande ci-dessus:

whoami
/usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg

Pourquoi ces commandes? Je suis assez confiant que votre problème est un problème d'autorisation/usercontext et les commandes suivantes aggravent encore la situation:

$ Sudo chown -R vagrant:vagrant /var/run/puppetlabs/
$ Sudo chown -R vagrant:vagrant /var/log/puppetlabs/
$ Sudo chmod -R 0755 /var/run/puppetlabs/

avec les cas ci-dessus, vous devez créer un fichier Sudo sur le bon contexte utilisateur pour que les fichiers soient en écriture, mais cela dépend si les autres données sont en écriture. Donc, vous pouvez essayer, mais je voudrais utiliser l'utilisateur de marionnettes créé pour le service

User=puppet

Ainsi, votre service de marionnettes fonctionne comme une marionnette d’utilisateur, mais vos fichiers journaux sont sous le contrôle d’un utilisateur vagabond et ne peuvent pas être écrits pour cet utilisateur.

Donc, je voudrais aussi essayer de revenir à:

$ Sudo chown -R puppet /var/run/puppetlabs/
$ Sudo chown -R puppet /var/log/puppetlabs/
$ Sudo chmod -R 0755 /var/run/puppetlabs/

Java

De plus, je vous suggère de ne PAS gâcher les paramètres de tas de la JVM, sauf que vous savez ce que vous faites. Étant donné que vous n'avez pas besoin d'appliquer une limite inférieure et maximale sur le segment de mémoire Java VM depuis JDK5. Je limiterais seulement à la limite supérieure 

-Xmx1g

Le tas et la mémoire allouée réelle seront bien gérés par la machine virtuelle Java. Au fur et à mesure que la JVM a besoin de plus, elle augmentera progressivement le tas et conservera la taille requise (aucune réduction de taille ne sera nécessaire). Ainsi, vous aurez une meilleure utilisation de la mémoire RAM sur votre machine.

Veuillez également basculer vers la machine virtuelle Java Oracle. Je suis souvent confronté à des problèmes de sécurité et de compatibilité avec OpenJDK. Mon premier test consiste donc à l'exécuter sur le dernier JDK d'Oracle nécessaire. Dans votre cas, Oracle JDK8 . Mais s'il vous plaît essayez d'abord les choses de permission que j'ai mentionnées auparavant.

Bonne chance et s'il vous plaît tenez-moi au courant.

1
cilap
/usr/bin/Java -Xms1g -Xmx1g -XX:MaxPermSize=1g

Xms et Xms sont inférieurs à MaxPermSize. cela a fonctionné pour moi.

0
Manula Doratiyawa

J'ai déjà vu ce comportement auparavant. N'essayez pas d'exécuter les commandes manuellement en tant qu'utilisateur root, car vous risqueriez de gâcher les autorisations. Au lieu de cela, lisez attentivement les journaux avec journalctl -xe et essayez de comprendre pourquoi le service échoue. Dans mon cas, je ne pouvais pas démarrer le service puppetserver car il y avait déjà une clé privée, mais pas encore de certificat public.

ls /etc/puppetlabs/puppet/ssl/certs/`hostname -f`.pem
ls /etc/puppetlabs/puppet/ssl/private_keys/`hostname -f`.pem

Si l'un d'eux est présent sans l'autre, le service ne pourra pas démarrer. Vous verrez quelque chose comme ceci dans le fichier journal:

Exception in thread "main" Java.lang.IllegalStateException: Cannot initialize master with partial state; need all files or none.

Si vous essayez d'installer puppetserver pour la première fois et qu'il n'y a donc aucun moyen de supprimer un déploiement existant, vous pouvez probablement simplement supprimer la clé privée existante et puppetserver générera automatiquement une nouvelle paire.

rm /etc/puppetlabs/puppet/ssl/certs/`hostname -f`.pem
rm /etc/puppetlabs/puppet/ssl/private_keys/`hostname -f`.pem

Et enfin, essayez à nouveau de démarrer le service puppetserver.

service puppetserver start
0
Thomas Lobker