2016-03-17 20 views
12

Possiedo un VM CentOS Vagrant in esecuzione con ps.memory = 2048 RAM allocata.Impossibile avviare il servizio Puppetserver

Quando provo ad avviare il servizio 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 

mio JAVA_ARGS da /etc/sysconfig/puppetserver:

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

Come richiesto, il file 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}" [email protected] 

KillMode=process 

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

SuccessExitStatus=143 

StandardOutput=syslog 

[Install] 
WantedBy=multi-user.target 

Un tentativo di esecuzione il ExecStartPost comando a mano:

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

Così ho provato di nuovo, ma questa volta ho cambiato alcune autorizzazioni di directory, ma ancora errore simile (che non ha senso dato Ho appena cambiato il modo?):

$ 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 

Quale potrebbe essere il problema?

+0

Si prega di fornire il file puppetserver.service – fge

+0

@fge: aggiunto alla domanda – lollercoaster

+0

_ "Vedere 'stato puppetserver.service systemctl' e 'journalctl -xn' per i dettagli." _ - Cosa significano questi dicono? –

risposta

2

Sei sicuro che si tratta di un errore OnOutOfMemory? Lo chiedo perché ho scoperto che l'ultimo PuppetServer include una nuova versione di logback, come mostrato da questo messaggio in/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) 

Se si vede, questo sostituire “classic.net.Syslog” in logback.xml con "core.net.Syslog"

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

Se questo non è il problema, si prega di inviare i vostri file di log.

+0

Ah, sì, penso che potresti avere ragione. Il problema potrebbe essere che il comando 'ExecStartPre' sta chowning'/var/run/puppetlabs/puppetserver' per essere user = puppet, group = puppet. Vedo che quando I 1) chown a 'vagrant: vagrant', 2) tenta di iniziare, 3) continua a fallire, 4)'/var/run/puppetlabs/puppetserver' è ora di proprietà di 'puppet: puppet' (che si adatterebbe con gli errori permanenti sopra). L'errore sembra ancora lo stesso di quando ho postato nella domanda sopra tuttavia. – lollercoaster

+0

Dovrei aggiungere che non sembra che sia stato risolto il commento della riga 'ExecStartPre' nel file env. – lollercoaster

+0

E l'esecuzione del comando 'ExecStart' con' sudo' restituisce ancora errore: 'RuntimeError: ottenuto 2 errori durante l'inizializzazione: File [/ var/log/puppetlabs/puppetserver]: modifica da 0700 a 0750 non riuscita: impossibile impostare modalità 0700 su/var/log/puppetlabs/puppetserver: Operazione non consentita - Nessun messaggio disponibile; File [/ var/run/puppetlabs/puppetserver]: modifica da 0775 a 0755 non riuscita: impossibile impostare la modalità 0775 su/var/run/puppetlabs/puppetserver: Operazione non consentita - Nessun messaggio disponibile'. – lollercoaster

1

Hai fornito di registro come

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=1g; support was removed in 8.0

Quindi, è chiaro che si sta utilizzando JDK 8 che ha rimosso lo spazio PermGen.

Lo spazio Permanent Generation (PermGen) è stato completamente rimosso ed è sostituito da un nuovo spazio denominato Metaspace. Le conseguenze della rimozione di PermGen sono che ovviamente gli argomenti PermSize e MaxPermSize JVM vengono ignorati e non si otterrà mai uno java.lang.OutOfMemoryError: PermGen error.

  1. Quindi, per favore rimuovere la parte -XX:MaxPermSize=1g da JAVA_ARGS di posizione /etc/sysconfig/puppetserver

JAVA_ARGS="-Xms1g -Xmx1g"

Così

  1. E poi,

tua il comando sarà simile al seguente:

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

o

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

Si prega di provare questo 2 comandi. Spero che entrambi funzioneranno correttamente. Per prudenza, ho aggiunto entrambi.

N.B: Non è necessario modificare il permesso del file. mantienili come prima di usarli.

In caso contrario, se non si vuole cambiare nulla, è possibile effettuare il downgrade a java 8java 7

link correlati:

  1. PermGen elimination in JDK 8
  2. Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize
  3. JAVA 8 XX:PERMSIZE AND XX:MAXPERMSIZE DISAPPEARING
  4. JDK 8 Milestones
  5. JEP 122: Remove the Permanent Generation
1

@lollercoster, si sta iniziando il vostro servizio con:

sudo puppet resource service puppetserver ensure=running 

Ma il secondo comando non dice quale utente è

/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 

Eseguire whoami direttamente prima di eseguire il comando precedente:

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 

Perché questo comando? Io sono abbastanza sicuro che il tuo problema è un/problema UserContext permesso e seguenti comandi rendono più peggio:

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

con i casi di cui sopra si deve fare un sudo sul contesto dell'utente diritto di avere i file scrivibili, ma dipende se gli altri dati sono scrivibili. Così si può fare un tentativo, ma vorrei utilizzare l'utente fantoccio creato per il servizio

User=puppet 

Così il vostro servizio fantoccio viene eseguito come burattino utente, ma i vostri file di log sono sotto il controllo dell'utente vagabonda, e non scrivibile per l'utente fantoccio .

Quindi vorrei anche provare a tornare a:

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

Java

anche che non pasticciare con i parametri JVM heap, ti suggerisco tranne voi sapete quello che fate. Dal momento che non è necessario imporre un limite inferiore e massimo sull'heap della VM Java da JDK5. Avrei solo limitare al limite superiore

-Xmx1g 

Il mucchio e il reale assegnati mem sarà gestito bene dalla JavaVM. Man mano che JVM ne ha bisogno, aumenterà gradualmente l'heap e manterrà la dimensione necessaria (non si verificherà ridimensionamento a un valore inferiore). Quindi avrai una RAM usata migliore sulla tua macchina.

Inoltre, passare a Oracle JVM. Sto affrontando spesso problemi di sicurezza e compatibilità con OpenJDK. Quindi il mio primo test è eseguirlo sull'ultimo JDK di Oracle necessario. Nel tuo caso Oracle JDK8. Ma per favore prima prova le cose di autorizzazione che ho menzionato prima.

Buona fortuna, e per favore tenetemi aggiornato.

0

Ho visto questo comportamento prima. Non tentare di eseguire i comandi manualmente come root, poiché si avranno dei problemi con le autorizzazioni. Leggere invece i registri attentamente con journalctl -xe e cercare di capire perché il servizio non funziona. Nel mio caso non è stato possibile avviare il servizio puppetserver perché esisteva già una chiave privata, ma non ancora un certificato pubblico.

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

Se uno di questi è presente senza l'altro, il servizio non verrà avviato. Vedrete qualcosa di simile nel file di registro:

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

Se si sta tentando di installare puppetserver per la prima volta, quindi non c'è modo per rompere una distribuzione esistente, allora probabilmente si può semplicemente rimuovere il privato exisiting il tasto e puppetserver genererà automaticamente una nuova coppia.

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

E infine riprovare per avviare il servizio puppetserver.

service puppetserver start