2016-03-17 21 views
12

Mam maszynę VM CentOS VM z przydzieloną pamięcią ps.memory = 2048.Usługa Puppetserver nie uruchamia się

Gdy próbuję uruchomić usługę 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 

My JAVA_ARGS z /etc/sysconfig/puppetserver:

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

Zgodnie z wnioskiem, plik 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 

Próba biegu ExecStartPost komenda ręcznie:

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

Więc spróbował ponownie, ale tym razem zmieniłem pewne uprawnienia katalogów, ale wciąż podobny błąd (co nie ma sensu, biorąc pod uwagę właśnie zmienił tryb):

$ 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 

Co może być problemem?

+0

Proszę podać plik puppetserver.service – fge

+0

@fge: Dodano do pytania – lollercoaster

+0

_ "widzieć 'status puppetserver.service systemctl' i 'journalctl -xn' szczegóły." _ - co ci mówią? –

Odpowiedz

2

Czy jesteś pewien, że jest to błąd OnOutOfMemory? Pytam, bo okazało się, że ostatni PuppetServer zawiera nowszą wersję logback, jak pokazano w niniejszym komunikacie w/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) 

Jeśli widzisz, to zastąpić „classic.net.Syslog” w logback.xml z "core.net.Syslog"

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

Jeśli to nie jest problem, opublikuj swoje logi.

+0

Ach, tak, myślę, że możesz mieć rację. Problem może polegać na tym, że komenda 'ExecStartPre' chowninguje'/var/run/puppetlabs/puppetserver' na user = marionetka, group = marionetka. Widzę, że kiedy 1) chown do 'vagrant: vagrant', 2) staram się zacząć, 3) nadal kończy się niepowodzeniem, 4)'/var/run/puppetlabs/puppetserver' jest teraz własnością 'kukiełki: lalek' (który pasowałby do błędów permsowych powyżej). Błąd nadal wygląda tak samo, jak w przypadku zamieszczenia powyższego pytania. – lollercoaster

+0

Powinienem dodać, że komentowanie linii 'ExecStartPre' w pliku env nie wydaje się naprawić. – lollercoaster

+0

Użycie polecenia 'ExecStart' z' sudo' nadal powoduje błąd: 'RuntimeError: Wystąpiły 2 błędy podczas inicjalizacji: Plik [/ var/log/puppetlabs/puppetserver]: zmiana z 0700 na 0750 nie powiodła się: nie udało się ustawić tryb 0700 na/var/log/puppetlabs/puppetserver: Operacja niedozwolona - Brak komunikatu; Plik [/ var/run/puppetlabs/puppetserver]: zmiana z 0775 na 0755 nie powiodła się: nie udało się ustawić trybu 0775 na/var/run/puppetlabs/puppetserver: Operacja niedozwolona - Brak komunikatu ". – lollercoaster

1

Ty dostarczyły dziennik jako

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

Tak, to jest oczywiste, że używasz JDK 8, która usuwa PermGen miejsca.

Przestrzeń permanentnej generacji (PermGen) została całkowicie usunięta i jest zastąpiona nową przestrzenią o nazwie Metaspace. Konsekwencją usunięcia PermGen jest to, że argumenty JVM PermSize i MaxPermSize są ignorowane i nigdy nie otrzymasz java.lang.OutOfMemoryError: PermGen error.

  1. Więc proszę usunąć część -XX:MaxPermSize=1g z JAVA_ARGS lokalizacji /etc/sysconfig/puppetserver

JAVA_ARGS="-Xms1g -Xmx1g"

Więc

  1. A potem,

swoje polecenie będzie wyglądać jak poniżej:

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

lub

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

Spróbuj to 2 polecenia. Mam nadzieję, że obie będą pomyślnie działać. Ze względu na ostrożność dodałem oba.

N.B: Nie ma potrzeby zmiany uprawnienia do pliku. zachowaj je jak przed użyciem.

W przeciwnym razie, jeśli nie chcesz nic zmieniać, można obniżyć java 8 do java 7

powiązany link:

  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, zaczynasz swoją usługę z:

sudo puppet resource service puppetserver ensure=running 

Ale następnym polecenie nie jest informacją, której użytkownik jest

/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 

Proszę uruchomić bezpośrednio whoami przed uruchomieniem powyższego polecenia:

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 

Dlaczego to polecenie? jestem całkiem pewny, że Twój problem jest pozwolenie/usercontext problem i następujące polecenia uczynić go bardziej gorzej:

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

z powyższych przypadkach trzeba zrobić sudo na właściwym kontekście użytkownika, aby mieć pliki zapisywalny, ale zależy to od tego, czy inne dane są zapisywalne. Więc można spróbować, ale chciałbym skorzystać z utworzonej za usługę użytkownikowi lalkowy

User=puppet 

więc usługa lalek działa jak marionetka użytkownika, ale twoje logi są pod Vagrant kontrolą użytkownika, a nie do zapisu dla użytkownika lalek .

Więc chciałbym również spróbować wrócić do:

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

Java

również sugeruję, żebyś nie poeksperymentować z parametrami JVM sterty, chyba wiesz, co robisz. Ponieważ nie trzeba wymuszać niższego i maksymalnego powiązania sterty wirtualnej maszyny Java od czasu JDK5. Ograniczałbym się tylko do górnej granicy: javaVM będzie zarządzał dobrze stertą i prawdziwym przydzielonym memem tylko do górnej granicy. Ponieważ JVM potrzebuje więcej, będzie stopniowo zwiększał stertę i utrzymywał wymagany rozmiar (nie nastąpi zmniejszenie rozmiaru do niższej wartości). Będziesz miał lepiej wykorzystaną pamięć RAM na swoim komputerze.

Należy również przejść do Oracle JVM. Mam często problemy z bezpieczeństwem i kompatybilnością z OpenJDK. Więc moim pierwszym testem jest uruchomienie go na najnowszym, potrzebnym JDK Oracle. W twoim przypadku Oracle JDK8. Ale proszę najpierw wypróbuj to, o czym wspomniałem wcześniej.

Powodzenia i proszę informuj mnie na bieżąco.

0

Widziałem to zachowanie wcześniej. Nie próbuj uruchamiać poleceń ręcznie jako root, ponieważ zepsujesz uprawnienia. Zamiast tego przeczytaj uważnie dzienniki za pomocą journalctl -xe i spróbuj zrozumieć, dlaczego usługa nie działa. W moim przypadku nie mogłem uruchomić usługi puppetserver, ponieważ był już prywatny klucz, ale jeszcze nie był to certyfikat publiczny.

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

Jeśli jeden z nich jest obecny bez drugiego, usługa nie uruchomi się. będzie można zobaczyć coś takiego w pliku dziennika:

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

Jeśli próbujesz zainstalować puppetserver po raz pierwszy, więc nie ma sposobu, aby przełamać istniejące stanowisko, a następnie prawdopodobnie można po prostu usunąć objąć istniejącymi prywatne key i puppetserver automatycznie wygeneruje nową parę.

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

I wreszcie spróbuj ponownie uruchomić usługę puppetserver.

service puppetserver start 
Powiązane problemy