So gehe ich vor:
1) Benutzer erstellen some_deployer
2) dann Ordner zum Skripten erstellen wie /company/script/<service name>
3) in diesem Ordner erstelle ich die start.shSkripte stop.shund gebe dem Benutzer den Besitz some_deployerund die Berechtigung mit chmod 755.
4) dann das Skript im /etc/init.d/Ordner erstellen wie <service name>-serviceund gebe dem Benutzer den Besitz some_deployerund die Berechtigung mit chmod 755.
5) dann diesen Dienst zur Liste der Dienste hinzufügen, immer noch innerhalb des /etc/init.d/mit
/sbin/chkconfig --add -service (Suse) oder update-rc.d <service name>defaults (Ubuntu)
Ist das richtig? Ist das die beste Vorgehensweise? Ich frage, weil einer der Dienste, die ich gerade erstelle, plötzlich nicht mehr funktioniert. Ich versuche den Befehl /etc/init.d/-service und er sagt, dass das der Fall ist. command is not foundWarum ist das so?
Antwort1
Es ist nicht notwendig, einen Benutzer zu erstellen, aber Sie können es auf jeden Fall tun, wenn es zu Ihrem Vorteil ist. Ich bin mir nicht sicher, was Sie mit /company/script/ meinen, aber es gibt keinen Grund, es nicht zu tun. Stellen Sie einfach sicher, dass sich Ihre Skriptdatei in /etc/init.d befindet, bevor Sie update-rc.d ausführen. Ich bin mir nicht sicher, warum Sie /company/script/ verwenden möchten, aber Ihrem Fehler zufolge kommt Ihr Dienstname nicht durch.
Sehen Sie sich hier die LSB-Spezifikationen für ein init.d-Skript an:http://wiki.debian.org/LSBInitScripts Sie erstellen ein einzelnes Skript mit den Funktionen Stopp/Start/Neustart/Force-Reload/Status und registrieren es dann mit update-rc.d oder was auch immer Sie vorgeschlagen haben. Dadurch kann update-rc.d auf eine einzelne Datei verweisen, aber alle erforderlichen Vorgänge damit ausführen.
Antwort2
Glauben Sie nicht zu sehr an LSB, die meisten Distributionen haben es schon lange aufgegeben sysvinit, Ubuntu, RHEL verwenden es upstart(im Fall von RHEL meist im SysV-Kompatibilitätsmodus), Fedora verwendet es systemdseit mehr als einem Jahr, in Fedora 18 sind fast alle Dienste natives systemd. Eines der Versprechen von systemd ist, weiterhin LSB-kompatible Setups zu handhaben, aber es bietet viele Vorteile, wenn die native Konfiguration verwendet wird. Sehen Sie sich seine umfangreicheDokumentation.