Jak aktywować uruchamiane logowanie w OS X?


35

Jak aktywować uruchamiane logowanie w OS X 10.6?

Dodałem nowego demona, który nie uruchamia się poprawnie (status to 1).

Chcę debugować problem, ale nie udało mi się znaleźć launchddzienników, których nie ma /var/log/launchd.log.

Odpowiedzi:


26

Znalazłem rozwiązanie

 sudo launchctl log level debug 

a potem

 tail -f /var/log/system.log

1
Zdałem sobie sprawę, że ten system operacyjny potrzebuje administratora, podobnie jak wszystko inne. Szukałem tego całkowicie po dniu krzyczenia „WTF gdzie jest pełna flaga!” OSX działa, oczywiście, ale trudne do opanowania. Dzięki +1
chiggsy

Kontynuacja, FYI: Działa to również z OS X 10.7.2. Dzięki.
Alan W. Smith,

Mam problemy z serwerami Leoparda i pomyślałem, że coś było nie tak z uruchomioną listą (choć ta sama listwa działa w systemie Snow Leopard).
Natknąłem się

27
To już nie działa od 10.10 Yosemite. wersja launchctl: Darwin System Bootstrapper 2.0.0: Wt 9 września 16:30:56 PDT 2014
JeanMertz

9
@JeanMertz - jakaś alternatywa?
Umang,

20

Zakładając, że próbujesz zarejestrować swój proces, a nie sam się uruchomić, jeśli w uruchomionym pliku plist zostaną uwzględnione następujące wiersze:

<key>StandardOutPath</key>
<string>/path/to/logfile.log</string>
<key>StandardErrorPath</key>
<string>/path/to/another_logfile.log</string>

i ponownie załadować proces, wszelkie rejestrowanie lub drukowanie wewnętrzne skryptu będzie przechwytywane w jednym z tych dwóch plików przy każdym uruchomieniu. chociaż obracanie plików zależy od Ciebie. jak można się spodziewać, jeśli użyjesz tego samego pliku w obu instancjach, zarejestruje on zarówno błąd, jak i standardowe wyjście w tym samym miejscu.

Patrz: Debugowanie uruchomionych zadań w sekcji Tworzenie demonów i agentów uruchamiania .


17

W systemie OS X 10.11 (El Capitan) można użyć, sudo launchctl debug <service-target> --stdout --stderraby włączyć rejestrowanie jednorazowe, jeśli nie chcesz korzystać z opcji systemu plików sugerowanej przez @peter.

Wiele rzeczy różni się w obecnej implementacji launchctli <service-target>jest to trochę dziwne. Załóżmy na przykład, że mam skonfigurowaną usługę lokalną ~/Library/LaunchAgents/dev.localmon.plist, która ma „etykietę” dev.localmon. To <service-target>jest gui/$UID/dev.localmon, gdzie $UIDjest twój identyfikator użytkownika, który, ponieważ uruchamiasz to w CLI, twoja powłoka interpoluje dla ciebie.

Załóżmy więc, że moja dev.localmonusługa uległa awarii podczas uruchamiania (tak było), mógłbym wywołać następujące polecenie, aby launchctlprzepuścić stdout procesu i stderr do mojej powłoki przy następnym (i tylko następnym razem) uruchomieniu usługi:

sudo launchctl debug gui/$UID/dev.localmon --stdout --stderr

Ponieważ zawiesza się z otwartymi i gotowymi terminalami TTY, przejdź do innego terminala i uruchom:

launchctl start dev.localmon
# start is a legacy command and doesn't use the fancy new service-target notation

Następnie, z powrotem w pierwszym terminalu, powinieneś zobaczyć wynik. (Dziwne, nie zamyka się, gdy proces usługi umiera, więc musisz nacisnąć Ctrl + C).

Btw, po naprawieniu pliku konfiguracyjnego za pomocą PATH lub środowiska, które wcześniej przerywało usługę, nadal musisz użyć starego launchctl unload ~/Library/LaunchAgents/dev.localmon.plist && launchctl load ~/Library/LaunchAgents/dev.localmon.plistdwuetapowego kroku, ponieważ rzekoma uncachekomenda dokumentacji ma następujący efekt:

Polecenie nie zostało jeszcze zaimplementowane.

Yay dla strategii Apple po opublikowaniu oferty pracy: „Poruszaj się szybko i niszcz rzeczy”


sudo launchctl debugwychodzi ze Could not find domain formną
Tom
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.