Welches Betriebssystem nutzt du, dass du noch auf SysV Init zurückgreifst?
Debian 8 hat doch systemd. Guck dir mal bitte den Umgang mit systemd an.
systemctl start psa
systemctl stop psa
systemctl status psa
journalctl -u psaOder gibt es einen Grund, dass du noch explizit SysV init nutzt (was im Endeffekt nur eine Umleitung dessen ist)?
H6G Sorry aber das tut doch gar nichts zur Sache, oder? Ich will dich nicht angreifen. Ich wäre nur dafür, auf konkrete Fragen einzugehen und nicht in Richtung "Ich hab aber mehr Ahnung als du" auszuschweifen... Unter Ubuntu 18.04 kann man auch zum Beispiel noch problemlos den
service apache restartBefehl benutzen, ohne irgendwelche Probleme. Schön, dass du weißt, wie es 100% korrekt wäre, aber "/etc/init.d/psa stop" funktioniert doch auch. (Korrigiere mich gerne, wenn es vernünftige Gründe gibt, das nicht mehr zu nutzen) 
sv3n : Ich kann das nicht mit absoluter Sicherheit sagen, aber bei mir wurde der Plesk Prozess schonmal gekillt (Oberfläche auf Port 8443 nicht erreichbar) aber die Webseiten inklusive Datenbanken liefen einfach weiter. Soweit zumindest meine Erfahrung. Ich denke aber, dass es sinnvoller wäre, den Plesk Prozess laufen zu lassen und (wenn es um Sicherheit geht) per Firewall den Port 8443 von außen zu blocken..
Hoffe das hilft weiter.
Viele Grüße
marpri
Schön, dass du weißt, wie es 100% korrekt wäre, aber "/etc/init.d/psa stop" funktioniert doch auch. (Korrigiere mich gerne, wenn es vernünftige Gründe gibt, das nicht mehr zu nutzen)
Ja natürlich funktioniert das auch. Aber wo ist eine Verkettung von init Prozessen sinnvoll? Nirgens steht, dass das init Script dahinter die Befehle an systemd weiter reichen muss - und ich persönlich bearbeite lieber eine .service Datei als ein init Script - zumal der runlevel Dienst Plesk bestimmt über systemd startet (in dem Fall multi-user.target) und die Abhängigkeiten anders berechnet.
Und meistens deutet soetwas auf ein veraltetes Betriebssystem hin - und dann kann man immer noch den Hinweis geben: zieh dir mal ein OS Upgrade.
In diesem Fall nicht notwendig sondern nur ein Ausdruck von administrativer Individualität (das haben wir schon immer so gemacht )
Die von marpri gezeigte Möglichkeit über service funktioniert auch unter Debian noch immer. Der Vorteil dieses Wrappers ist außerdem, dass er unabhängig vom installierten Init-System funktioniert. Für simple start/stop/restart/status Sachen, vor allem in Scripten ist das nach wie vor die erste Wahl.
Sorry, und nun back2topic 
Hay,
Korrigiere mich gerne, wenn es vernünftige Gründe gibt, das nicht mehr zu nutzen
ich bleibe doch mal kurz off-topic, einen der Gründe habe ich vor einer Woche life erlebt.
"Früher" hatte man openvpn mit /etc/init.d/openvpn start gestartet. Dieses Script (also "damals" (tm)) hat alle .config-Dateien im /etc/openvpn automatisch geladen, dadurch waren sofort alle configs aktiv. Das openvpn, was in meiner Distribution auf dem Server zuhause verwendet wird (opensuse), läuft natürlich über systemd und einem wrapper-Script in /etc/init.d/. Openvpn läuft auf meinem Heimserver seit Jahren wunderbar als client (also mit einer klassischen /etc/openvpn/client.conf). Letzte Woche hatte ich außer Haus zu tun und brauchte Zugriff auf eine VM zuhause.
Also "schnell" mal eine server.conf erstellt und wie seit Ewigkeiten /etc/init.d/openvpn restart getippt.
Client war da, Openvpn Server nicht. Noch nichtmal Logeinträge. Hä?
Ich war zuerst nicht darauf gekommen und habe alles andere überprüft - Keys (da erstelle ich aus Versehen gerne mal Server-Keys für clients...), Port, MTU, ciphers und der ganze Quatsch. Aber dann müsste es doch Logeinträge geben!
Schließlich habe ich nach 10 wütenden Minuten entdeckt, dass der systemd mit dem init.d-Script einfach nur die client.conf startet (und zwar explizit nur genau diese config). Schnelle Lösung hier war, einfach das systemd-Objekt mit der client.config zu kopieren, das File zu editieren, dass es die server.config geladen wird und dann mit einem eigenen Namen zu aktivieren und zu starten. Et voila: ging dann sofort und ich hatte meine Logfile-Einträge.
Und das ist extrem unerwartetes Verhalten, wenn man sich noch nicht an das Handling von systemd gewöhnt hat und mir persönlich war es eine Lehre.
CU, Peter
CmdrXay unter systemd gibt es Subservices zu erkennen an der openvpn@.service - die Konfigurationen muss man also einmal erst registrieren, damit diese starten.
In dem Hauptservice wird dann meistens nur kurz /bin/true gestartet.
systemctl enable openvpn@server
systemctl start openvpn@serverHay,
unter systemd
klingt rückständig, aber ich suche nach einem guten Buch zu systemd. Die online-Dokus mag ich nicht, die sind in meinem Augen nicht zum Lernen geschrieben, damit löse ich nur anlaßbezogen Unannehmlichkeiten, auf die ich gerade stoße. Oder einen echten Online-Kurs, das wäre noch eine Alternative.
CU, Peter
https://www.freedesktop.org/wiki/Software/systemd/ =>The systemd for Administrators Blog Series reicht mir eigentlich vollkommen aus. Der Typ scheint Ahnung davon zu haben Was fehlt dir da?
Der Typ scheint Ahnung davon zu haben
Könnte daran liegen, dass das Poetterings Blog ist.
Hay,
Was fehlt dir da?
das Konzept. Ein (gutes) Buch hat immer ein übergreifendes Konzept und ist in sich abgeschlossen. Abgesehen vom didaktischen Ansatz. Ein gutes Buch hat so viel mehr als ein Blog mit hunderten von Quellenangaben. Ein Buch hat etwas meditatives, ein Blog fördert wildes rumgeklicke und das sich-verlieren in Referenzen, weil ein Thema nicht besprochen wird, sondern woanders hin verwiesen wird und man wird im Verweis mit einem komplett anderen Schreibstil, Ansatz oder anderer Qualität konfrontiert. Ein anderer Aspekt ist, dass man beim Online-Lesen von Quellenmaterial auch immer (mindestens in den Kommentaren) mit hating und trolling bezüglich systemd konfrontiert wird, was äußerst störend und ablenkend wirkt, weil es nicht zielführend ist. Das kann man nicht einfach so ausblenden.
Hier aber einen Aufsatz "über den Vorteil eines Buches" zu schreiben wäre der falscher Ort Ich will halt eins und das hat seinen Grund.
CU, Peter
