Ersehen, ob Service läuft

[tfc]

Habe es längst im Script eingebaut.

service --test-if-configured-on ssh &> /dev/null;
if [ $? = 0 ]; then 
    sshServ="running";
else 
    sshServ="offline"; 
fi

Funktioniert genau so wie gebraucht.

 

[MacMark]

Hm, also aktiviert und deaktiviert über das Sharing-Panel via GUI klappt es bei mir wunderbar...

Der GUI-Haken ist ebenso unzuverlässig wie der service-Befehl. Das läßt sich leicht mit einem ssh-Verbindungsversuch testen.

 

[Rastafari]

Der GUI-Haken ist ebenso unzuverlässig wie der service-Befehl. Das läßt sich leicht mit einem ssh-Verbindungsversuch testen.

man service

Keiner hat gesagt, dass du mit launchctl "unter die Haube" greifen und daemons manuell starten/stoppen sollst. Du musst doch nicht irgendwie zwanghaft direkt mit dem Prozess 1 reden, oder?
Benutze das vorgesehene Kommando und gut ist es.

 

[MacMark]

man service

Keiner hat gesagt, dass du mit launchctl "unter die Haube" greifen und daemons manuell starten/stoppen sollst. Du musst doch nicht irgendwie zwanghaft direkt mit dem Prozess 1 reden, oder?
Benutze das vorgesehene Kommando und gut ist es.

Das ist inkorrekt. Er hat danach gefragt, wie wir hier leicht nachlesen können:

... Da beispielsweise SSH nicht in der Prozessliste auftaucht, wird es wohl einen Überservice geben, der den entsprechenden Daemon bei Bedarf startet.

Der Überservice/Prozeß, nach dem er fragt, ist launchd. Seine Analyse "bei Bedarf" war daher sogar korrekt, denn das ist eine zentrale Aufgabe von launchd, Dienste nach Bedarf zu starten.

Welcher Prozess ist das und wie arbeite ich damit?

Der Prozeß heißt launchd und man arbeitet über launchctl (launch control) mit ihm.

Es wäre auch interessant für mich zu erfahren, wie ich ihn per Konsole bediene, um die Services selbst zu starten und zu beenden...

Das ist launchctl mit den oben von mir gezeigten Kommandos (oder auf meiner Seite).

Falls Du, Rastafari, "service" für das vorgesehene Kommando hältst, habe ich so meine Zweifel, weil der Befehl zumindest bei mir nicht in der Lage war, ssh an- und abzuschalten. Seit 10.4 ist launchd und die dafür _vorgesehene_ Kommunikationsschnittstelle launchctl dafür zuständig, Dienste wie ssh zu verwalten. Und da ssh nunmal in der Regel ein systemweiter Dienst ist, kommt man um "process 1" nicht herum.

 

[Rastafari]

Falls Du, Rastafari, "service" für das vorgesehene Kommando hältst

Apple tut das. Die haben das Skript (!) nicht umsonst geschrieben. Lies es und verstehe.
(Tip am Rande: Du musst die Systemeinstellungen schliessen und neu starten, damit das Programm seine angezeigten Daten aktualisiert.)

 

[MacMark]

Im "service" funktioniert das Starten und Stoppen nicht zuverlässig, weil sie die "-F"-Option nicht verwenden. Das service-Skript macht abgesehen davon exakt den Aufruf, den ich oben beschrieben habe. Das erklärt, warum start/stop mit service bei mir für ssh nicht wirkt. Das service-Skript ist teilweise ein Wrapper um launchctl - ein nicht ausreichender Wrapper.
http://www.opensource.apple.com/darwinsource/10.4.9.x86/launchd-106.20/launchd/src/service

Daß Apple dieses Skript für das Standard-Werkzeug hält, sehe ich dort nicht. Wie kommst Du darauf?

Service ruft auch launchctl auf, fummelt also ebenso unter der Haube herum wie mein Vorschlag. Von daher war Dein Einwand, ich würde unter der Haube fummeln, voreilig, macht doch Deine Alternative das gleiche - nur unzuverlässiger.

 

[Rastafari]

Im "service" funktioniert das Starten und Stoppen nicht zuverlässig, weil sie die "-F"-Option nicht verwenden.

Welche -F Option denn?
Diesen Switch gibts nur in der Server-Variante, um der geänderten Setup-Prozedur gerecht zu werden. Der dient der gezielten Übersteuerung von in der GUI getroffenen Einstellungen durch den Systemassistenten und ist nicht zur gewöhnlichen Benutzung gedacht.

Daß Apple dieses Skript für das Standard-Werkzeug hält, sehe ich dort nicht. Wie kommst Du darauf?

Rate mal, welches Backend von "System Preferences.app" benutzt wird. Und warum.

Von daher war Dein Einwand, ich würde unter der Haube fummeln, voreilig, macht doch Deine Alternative das gleiche - nur unzuverlässiger.

Im Gegenteil. Es handhabt auch das angestaubte xinetd-Zeugs richtig, das noch nicht an launchd angepasst ist (sofern noch vorhanden).
Und es wird als "High Level" Aufruf auch zukünftig für eine konsistente Bedienung aller daemons sorgen. Es war leider deine Kommandozeile, die versionsspezifisch und damit de Facto falsch war. Die Verwendung von "service" hätte das (für dich transparent) vermieden.

 

[MacMark]

Den "-F"-Switch gibt es auch bei meiner Nicht-Server-Version von OS X. Er ist auch in der manpage dokumentiert. Er erzwingt das Laden der plist und ignoriert den disabled-Eintrag darin. Beispiel:
sudo launchctl load -F /System/Library/LaunchDaemons/ssh.plist

Service setzt auch diesen Befehl ab, aber ohne das "force", aber mit -w (write back), um die Konfigurationsdatei zu ändern, was ich nicht wollte.

Ich weiß nicht, wie System Preferences arbeitet, da es vermutlich (ich habe nicht nachgesehen) nicht Open Source ist. Woher weißt Du, wie es arbeitet?

Meine Kommandozeilen funktionieren sowohl für das Starten als auch das Stoppen und das Auflisten des SSH-Dämons. Die Verwendung von "service" hingegen versagte bei mir sowohl für das Starten als auch für das Stoppen und für das korrekte Auflisten des SSH-Dämons. Ich bevorzuge Lösungen, die _funktionieren_.

Launchctl arbeitet sogar interaktiv, wenn man nur launchctl eingibt. Und launchd soll die Verwaltung aller Dämonen vereinheitlichen und bietet sogar weitgehende xinetd-Kompatibilität. Für den Übergang (Migration alter Dienste) ist service dann sicher nützlich, aber für Dämonen, die definitiv an launchd angepaßt sind (wie SSH), besteht kein Grund sie nicht (wie vorgesehen) mit launchctl zu verwalten, sondern mit einem Skript (service), was den Möglichkeiten eines launchd-Dämons nicht gerecht wird.

 

[Rastafari]

Den "-F"-Switch gibt es auch bei meiner Nicht-Server-Version von OS X. Er ist auch in der manpage dokumentiert.

In meiner nicht. Seltsam, was? Mag vielleicht daran liegen, dass ich nicht alles installiere, was mehr Hörner als ein Gnu hat.

Er erzwingt das Laden der plist und ignoriert den disabled-Eintrag darin. Beispiel:
sudo launchctl load -F /System/Library/LaunchDaemons/ssh.plist

Toll. Und wozu braucht Otto N. Ormalverbraucher das bitteschön?
Ausser vielleicht um Software zu schreiben, die sich so rüpelhaft verhält wie typische Mal- oder Spyware...

Service setzt auch diesen Befehl ab, aber ohne das "force", aber mit -w (write back), um die Konfigurationsdatei zu ändern, was ich nicht wollte.

Was du aber solltest. Ansonsten ist es doch ein wenig naiv bis plumpdreist sich darüber zu beklagen, dass die Systemeinstellungen von deiner Heimlichtuerei nichts mitbekommen. Wie sollten sie denn auch, wenn du die angedachte Funktionalität absichtlich sabotierst?

Ich weiß nicht, wie System Preferences arbeitet, da es vermutlich (ich habe nicht nachgesehen) nicht Open Source ist. Woher weißt Du, wie es arbeitet?

Manche lesen Nachrichten, andere verfassen sie, manche ignorieren sie, und wieder andere vergessen sie nur schnell. Ich bin mir relativ sicher, du hast das hier schon mal gelesen.

Meine Kommandozeilen funktionieren sowohl für das Starten als auch das Stoppen und das Auflisten des SSH-Dämons.

Sie funktionieren aber nicht zusammen mit der GUI.

Die Verwendung von "service" hingegen versagte bei mir sowohl für das Starten als auch für das Stoppen und für das korrekte Auflisten des SSH-Dämons. Ich bevorzuge Lösungen, die _funktionieren_.

Es kann sich als hilfreich erweisen, sein Getriebe nicht mit Sand zu schmieren. Das "Versagen" ist offensichtlich hausgemacht.

Launchctl arbeitet sogar interaktiv, wenn man nur launchctl eingibt.

Ach nee. Echt? Wirklich?
Na, dann kannst du die System Prefs und den ganzen Admin.framework ja löschen, oder?

Und launchd soll die Verwaltung aller Dämonen vereinheitlichen

Betonung auf soll. Da fliesst noch ein wenig Wasser den Bach runter bis dahin, meine ich.

für Dämonen, die definitiv an launchd angepaßt sind (wie SSH), besteht kein Grund sie nicht (wie vorgesehen) mit launchctl zu verwalten

Es besteht auch kein Grund, zum öffnen von Programmen oder Dokumenten sowas wie "open" zu verwenden. Warum tust du es?
Es besteht auch kein Grund, sowas wie Startskripte zu verwenden. Schliesslich kann man doch auch alle notwendigen Befehle bei jedem Systemstart von Hand eingeben, oder?

...mit einem Skript (service), was den Möglichkeiten eines launchd-Dämons nicht gerecht wird.

Irgendwas an diesem Satz lässt in mir Gedanken an den typischen "Overclocker" mit heliumgekühltem AMD-Turbo-GTI und Fuchsschwanz an der WLAN-Antenne aufkommen...
Tweake und frickle ruhig nach Herzenslust dein eigenes System zugrunde. Leite aber doch besser nicht unschuldige Opfer an, es dir gleich zu tun. Danke.

 

[MacMark]

Rastafari, Du solltest bei meinen Antworten bedenken, daß der Threadstarter den SSH-Dämon mit einem Skript steuern wollte. Es ging ausdrücklich _nicht_ um eine Alternative für Otto-Normalklicker.

Das Versagen von service ist nicht hausgemacht, denn service (siehe dessen source code) beachtet das disabled-Flag in der plist von ssh, weil service "-F" beim launchctl-Aufruf _nicht_ verwendet.

Falls mein "launchctl" mehr kann als Deines, dann liegt es allenfalls an den original Developer Tools von Apple.

An den Artikel erinnere ich mich wieder, hatte aber die Details nicht mehr im Kopf.

 

[Rastafari]

Das Versagen von service ist nicht hausgemacht, denn service (siehe dessen source code) beachtet das disabled-Flag in der plist von ssh, weil service "-F" beim launchctl-Aufruf _nicht_ verwendet.

Mit der Option -w wird dieses Flag umgeschaltet, aber nicht ignoriert. Es ist ja gerade der Sinn hinter "Disabled", dass ein launchctl-Aufruf OHNE diese Option "writeback" den sshd nicht startet. Sonst würde er nach einem Neustart ständig laufen, auch wenn du ihn deaktivierst.
Das Erzwingen der Aktivierung ohne Feedback an die GUI macht nur dann Sinn, wenn ssh von einem schreibgeschützten Startvolume temporär gestartet werden muss, zB während einer Remote-Installation.
(Die es nur für den Server gibt...)
Ansonsten ist er völlig unangebracht und fehl am Platz.

 

[MacMark]

Die Option -w schaltet nichts um und hat auch keinen Einfluß auf das Starten/Nichtstarten des Dämons, sondern schreibt den aktuellen Zustand, den man mit launchctl load oder unload herbeiführt (also geladen/nicht geladen aka disabled) in die plist, damit die Änderung permanent ist. Die -F Option forciert das Laden und ignoriert das disabled-Flag in der plist.

Aber schau selbst: "man launchctl" beginnt so:

launchctl [subcommand [arguments ...]]

DESCRIPTION
launchctl interfaces with launchd to load, unload daemons/agents and gen-
erally control launchd. launchctl supports taking subcommands on the
command line, interactively or even redirected from standard input.
These commands can be stored in $HOME/.launchd.conf or /etc/launchd.conf
to be read at the time launchd starts.

SUBCOMMANDS
load [-wF] paths ...
Load the specified configuration files or directories of config-
uration files.

-w Remove the disabled key and write the configuration
files back out to disk.

-F Force the loading of the plist. Ignore the Disabled
key.

unload [-w] paths ...
Unload the specified configuration files or directories of con-
figuration files.

-w Add the disabled key and write the configuration files
back out to disk.…

Meinetwegen können wir bei meinen Kommandos noch ein "-w" ergänzen Ich habe es weggelassen, damit man den Befehl ausprobieren kann, aber beim nächsten Neustart alles wieder wie vorher hat. Ich wollte dem Leser dieses Threads nicht seine plist verändern.


Ferner besteht ein Unterschied zwischen geladen und gestartet/laufen. Ich zitiere mich mal selbst aus
http://macmark.de/osx_launchd.php

"Geladen" und "gestartet" ist ein Unterschied. Ein Dämon oder Agent wird von launchd verwaltet, wenn er geladen wurde. Er kann manuell geladen werden oder (das ist der Normalfall) dadurch, daß seine Konfigurationsdatei in einem der Standardverzeichnisse liegt.

Ein geladener also von launchd verwalteter Agent oder Dämon wird gestartet/aktiv, also seine Tätigkeit durchgeführt, wenn er manuell gestartet wird oder (das ist der Normalfall) wenn eine Situation eintritt, die in seiner Konfigurationsdatei definiert wurde (Zeitpunkt, Intervall, Netzanfrage, Dateiänderung und so weiter).

Mit dem disabled-Flag auf true wird die plist des Dämons nicht geladen beim Systemstart und auch nicht beim normalen launchctl load ohne -F. Mit -F und launchctl kann man das jedoch erzwingen. Gestartet wird der Dämon jedoch erst, wenn im Falle von SSH eine Anfrage auf Port 22 reinkommt oder man ihn mit launchctl und start per Hand startet und er bereits geladen ist.

Aus man launchctl:

start joblabels ...
Start the specified jobs by label.

stop joblabels ...
Stop the specified jobs by label. Jobs may restart automatically
if demand driven.