wake-up-neo.net

Der Puppetserver-Dienst kann nicht gestartet werden

Ich habe einen Vagrant CentOS VM, der mit ps.memory = 2048 RAM belegt ist. 

Wenn ich versuche, den puppetserver-Dienst zu starten:

$ 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

Mein Java_ARGS von /etc/sysconfig/puppetserver:

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

Wie gewünscht, die puppetserver.service-Datei:

$ 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}" [email protected]

KillMode=process

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

SuccessExitStatus=143

StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Versuch, den Befehl ExecStartPost manuell auszuführen:

$ /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

Also habe ich es erneut versucht, aber diesmal habe ich einige Verzeichnisberechtigungen geändert, aber immer noch einen ähnlichen Fehler (was keinen Sinn macht, wenn ich nur den Modus geändert habe?)

$ 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

Was könnte das Problem sein?

12
lollercoaster

Sind Sie sicher, dass es sich um einen OnOutOfMemory-Fehler handelt? Ich frage, weil ich festgestellt habe, dass der neueste PuppetServer eine neuere Version von Logback enthält, wie in dieser Nachricht in/var/log/messages gezeigt:

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)

Wenn Sie sehen, ersetzen Sie "classic.net.Syslog" in "logback.xml" durch "core.net.Syslog".

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

Wenn das nicht das Problem ist, veröffentlichen Sie bitte Ihre Logfiles.

2
Jo Rhett

Sie haben das Protokoll als bereitgestellt

Warnung für OpenJDK 64-Bit-Server VM: Die Option MaxPermSize = 1g; .__ wird ignoriert. Unterstützung wurde in 8.0 entfernt

Es ist also klar, dass Sie jdk 8 verwenden, um den Permgenraum zu entfernen. 

Der permanente Generierungsbereich (PermGen) wurde vollständig entfernt und wird durch einen neuen Bereich mit dem Namen Metaspace ersetzt. Die Konsequenz der PermGen-Entfernung besteht darin, dass die JVM-Argumente PermSize und MaxPermSize offensichtlich ignoriert werden und Sie niemals einen Java.lang.OutOfMemoryError: PermGen error erhalten.

  1. Entfernen Sie also den -XX:MaxPermSize=1g-Teil von Java_ARGS des Speicherorts /etc/sysconfig/puppetserver

Java_ARGS = "- Xms1g -Xmx1g"

So 

  1. Und dann,

ihr Befehl wird wie folgt aussehen:

$ /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

oder

$ /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

Bitte probieren Sie diese 2 Befehle. Ich hoffe, dass beide erfolgreich laufen werden. Zur Vorsicht habe ich beides hinzugefügt.

NB: Die Dateiberechtigung muss nicht geändert werden. Behalten Sie sie wie vor dem Gebrauch.

Wenn Sie nichts ändern möchten, können Sie Java 8 auf Java 7 herabstufen.

In Verbindung stehender Link:

  1. PermGen-Eliminierung in JDK 8
  2. Warnung vor Java HotSpot (TM) 64-Bit Server VM: Option MaxPermSize wird ignoriert
  3. Java 8 XX: PERMSIZE UND XX: MAXPERMSIZE DISAPPEARING
  4. JDK 8 Meilensteine ​​
  5. JEP 122: Dauerhafte Generierung entfernen
2
SkyWalker

@lollercoster, Sie starten Ihren Dienst mit:

Sudo puppet resource service puppetserver ensure=running

Ihr nächster Befehl sagt jedoch nicht, um welchen Benutzer es sich handelt

/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

Bitte führen Sie whoami direkt aus, bevor Sie den obigen Befehl ausführen:

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

Warum diese Befehle? Ich bin ziemlich zuversichtlich, dass es sich bei Ihrem Problem um ein Berechtigungs-/Benutzerkontextproblem handelt und folgende Befehle machen es noch schlimmer:

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

in den oben genannten Fällen müssen Sie ein Sudo im richtigen Benutzerkontext ausführen, um die Dateien beschreibbar zu machen. Dies hängt jedoch davon ab, ob die anderen Daten beschreibbar sind. Sie können es also versuchen, aber ich würde den für den Dienst erstellten Marionettenbenutzer verwenden

User=puppet

Ihr Puppenservice wird also als Benutzerpuppe ausgeführt, Ihre Logfiles unterliegen jedoch der Kontrolle der Benutzer und sind für den Puppenbenutzer nicht beschreibbar.

Also würde ich auch versuchen zu wechseln:

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

Java

Ich schlage auch vor, Sie sollten sich NICHT mit den JVM-Heap-Parametern herumschlagen, es sei denn, Sie wissen, was Sie tun. Seit JDK5 müssen Sie für Java VM keinen Heap mehr als niedrig und maximal durchsetzen. Ich würde mich nur auf die obere Grenze beschränken 

-Xmx1g

Der Heap und das real zugewiesene Mem werden von der JavaVM gut verwaltet. Da die JVM mehr benötigt, wird der Heap schrittweise erhöht und die benötigte Größe beibehalten (es wird kein Downsizing auf einen niedrigeren Wert durchgeführt). Sie haben also einen besseren RAM auf Ihrem Rechner.

Wechseln Sie auch zur Oracle JVM. Ich habe häufig Probleme mit der Sicherheit und Kompatibilität mit OpenJDK. Mein erster Test ist also, es auf dem neuesten benötigten JDK von Oracle auszuführen. In Ihrem Fall Oracle JDK8 ... Bitte probieren Sie zuerst die Erlaubnisdinge, die ich zuvor erwähnt habe.

Viel Glück und bitte halten Sie mich auf dem Laufenden.

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

Xms und Xms sind weniger als MaxPermSize. das hat für mich funktioniert.

0

Ich habe dieses Verhalten schon früher gesehen. Versuchen Sie nicht, die Befehle manuell als root auszuführen, da Sie die Berechtigungen durcheinander bringen. Lesen Sie stattdessen die Protokolle sorgfältig mit journalctl -xe und versuchen Sie zu verstehen, warum der Dienst ausfällt. In meinem Fall konnte ich den puppetserver-Dienst nicht starten, da bereits ein privater Schlüssel vorhanden war, aber noch kein öffentliches Zertifikat.

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

Wenn einer von ihnen ohne den anderen vorhanden ist, kann der Dienst nicht gestartet werden. Sie sehen etwas in der Protokolldatei:

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

Wenn Sie versuchen, puppetserver zum ersten Mal zu installieren, sodass eine vorhandene Bereitstellung nicht unterbrochen werden kann, können Sie wahrscheinlich den vorhandenen privaten Schlüssel entfernen und puppetserver generiert automatisch ein neues Paar.

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

Versuchen Sie schließlich noch einmal, den Dienst puppetserver zu starten.

service puppetserver start
0
Thomas Lobker