Nie można uruchomić demona za pomocą launchctl w Yosemite


27

Mam uruchomionego demona, ~/Library/LaunchAgentsktóry działał dobrze w Mavericks. Ale nie rozpocznie się w publicznej wersji beta Yosemite. Plist demona jest taki (moja nazwa użytkownika to darksairUID 501)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.darksair.retrmail</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Users/darksair/bin/retrmail.py</string>
    </array>
    <key>KeepAlive</key>
    <false/>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>LaunchOnlyOnce</key>
    <false/>
    <key>UserName</key>
    <string>darksair</string>
    <key>ProcessType</key>
    <string>Standard</string>
    <key>EnvironmentVariables</key>
    <dict>
      <key>PATH</key>
      <string>/Users/darksair/Python/bin:/Users/darksair/Python3/bin:/Users/darksair/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>StandardOutPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
  </dict>
</plist>

Zasadniczo ma on działać ~/bin/retrmail.pyco 5 minut.

Zauważam, że w Yosemite uruchomiono aktualizację do 2.0, a launchctl ma nowe polecenia. próbowałem

sudo launchctl kickstart user/501/org.darksair.retrmail

i powiedział

Could not find service "org.darksair.retrmail" in domain for uid: 501

Próbowałem też starej szkoły

sudo launchctl load ~/Library/LaunchAgents/retrmail.plist

i powiedział

/Users/darksair/Library/LaunchAgents/retrmail.plist: Path had bad ownership/permissions

Plik jest własnością mnie i grupy pracowników. Próbowałem z uprawnieniami 644 i 600 z tym samym błędem.

Czy ktoś wie, jak prawidłowo odpalić uruchomionego demona w Yosemite?


AKTUALIZACJA: Wygląda na to, że mój plik agenta uruchamiania musi być własnością root:wheel. Po chown spróbowałem

sudo launchctl load ~/Library/LaunchAgents/retrmail.plist

i nie spowodowało to żadnego błędu. I myślę, że mój diamon działa poprawnie. Pozostawię to pytanie otwarte, ponieważ pamiętam, że uruchomiony dokument jasno stwierdza, że ​​plik agenta uruchamiania może być własnością użytkownika uruchamiającego demona.


UPDATE2: Nie, to nie działało poprawnie. Uruchomiono go tylko raz, ale nie ponownie, tak jakby został rozładowany.


AKTUALIZACJA 3: Uaktualniłem do publicznej wersji beta 3 Yosemite i zmieniłem mojego agenta na to

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.darksair.retrmail</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Users/darksair/bin/retrmail.py</string>
    </array>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>UserName</key>
    <string>darksair</string>
    <key>EnvironmentVariables</key>
    <dict>
      <key>PATH</key>
      <string>/Users/darksair/Python/bin:/Users/darksair/Python3/bin:/Users/darksair/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>StandardOutPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
  </dict>
</plist>

Ponownie załadowałem tego agenta i myślę, że teraz działa poprawnie. Nadal pozostawiam to pytanie otwarte, ponieważ nie wiem, co jest nie tak z moją poprzednią listą.


Podsumowując, znalazłem, że muszę zmienić właściciela plist root:wheel, aby go załadować.


Czy to działa w finale Yosemite?
TJ Luoma

@TJLuoma: tak. Tak długo, jak plist jest własnością root: wheel.
MetroWind,

Odpowiedzi:


21

Z man launchctl

Pamiętaj, że pliki konfiguracyjne dla poszczególnych użytkowników (LaunchAgents) muszą być własnością administratora (jeśli znajdują się w / Library / LaunchAgents) lub użytkownika, który je ładuje (jeśli znajdują się w $ HOME / Library / LaunchAgents). Wszystkie ogólnosystemowe demony (LaunchDaemons) muszą być własnością root. Pliki konfiguracyjne muszą zabraniać zapisu grupowego i światowego. Ograniczenia te obowiązują ze względów bezpieczeństwa, ponieważ umożliwienie zapisu w uruchomionym pliku konfiguracyjnym pozwala określić, który plik wykonywalny zostanie uruchomiony.

Fix is

sudo chmod 600 /Library/LaunchDaemons/x.plist
sudo chown root /Library/LaunchDaemons/x.plist

2
„Lub użytkownik je ładuje” <- Z tą częścią mam problem.
MetroWind,

2
Nie jestem facetem unixowym, ale mówi „nie zezwalaj na pisanie grup i świata”. Skoro nadal trzeba go czytać, prawda chmod 644?
Jason

5

O dziwo, używanie sudobyło twoim problemem. Korzystając z niego sudo, nie byłeś już sobą, więc nie byłeś właścicielem własnego pliku. Usuń sudo, powtórz polecenie i powinno się ładować w porządku. Przepraszam za filozoficzne podejście do tego wszystkiego.


4

Znalazłem rozwiązanie.

Prawidłowe polecenie w tym przypadku to

launchctl bootstrap gui/501 ~/Library/LaunchAgents/retrmail.plist

I rozładować,

launchctl bootout gui/501 ~/Library/LaunchAgents/retrmail.plist

Nie wiem jednak, dlaczego launchctl loadwymaga rootowania, ale ładowanie / rozładowywanie i tak jest przestarzałe.


Strona podręcznika wyświetla listę uruchamiania, a nie uruchamiania. Myślę, że autokorekta cię dopadła, ponieważ na moim komputerze zmienia bootowanie na bootcut.
Steve Moser

@MetroWind Dostaję Nie mogę znaleźć domeny dla błędu Code = 112 z powyższym poleceniem. to niespójne. jakaś wskazówka?
Parag Bafna

Czy nadal potrzebowałeś chmod& chown?
Itachi

@Itachi, nie. Pozostawienie domyślnego właściciela i pozwolenia powinno być w porządku.
MetroWind

@ParagBafna, nie jestem pewien. Może twój UID to nie 501?
MetroWind

3

Wpadłem również na to, próbując użyć użytkownika, a nie roota .plist (jak można to zrobić)

$ load ~/Library/LaunchAgents/com.blash.blah.plist
Could not find domain for 

Zostałem ssh-ededowany na tym komputerze zdalnie, kiedy NIE byłem zalogowany na konsoli (bez głowy), co wydawało się być moim problemem - przynajmniej usługi zarządzane przez użytkownika wymagają zalogowania się użytkownika na ekranie głównym (skończyłem logowanie przez zdalne zarządzanie, ponieważ jest to maszyna bezgłowa)

IMO, jeśli chcesz, aby to działało, nawet jeśli nie jesteś tam osobiście, aby zalogować się, możesz:

  • Ustaw automatyczne logowanie konta (zwróć uwagę na konsekwencje dla bezpieczeństwa, również bez znacznika UserName, jak podano w jednej z odpowiedzi)

  • Spraw, aby pliki były własnością roota, jak zaznaczono w różnych sugestiach (przywracanie użytkownika do twojego z UserName, jak już masz)


2
Dziękuję bardzo. Znalazłem rozwiązanie w twojej odpowiedzi.
Retraut,

2

Oto głupi pomysł.

Właśnie miałem ten sam błąd, także po aktualizacji do Yosemite. Przez pomyłkę założyłem, że oznacza to złe własności / uprawnienia do pliku .plist, gdy w rzeczywistości z jakiegoś powodu plik binarny, do którego odwoływałem się w liście (w moim przypadku Cassandra), stracił swój plik wykonywalny.

chmod + x'ing to naprawiło.

Prawdopodobnie nie twój problem, ale warto spróbować :)


Nie dotyczy to jednak mojej sprawy. Mój plik wykonywalny ma bit uprawnień x. Ale i tak dziękuję za odpowiedź. Mam nadzieję, że może to pomóc innym osobom.
MetroWind

2

Usuń UserNameklucz i ciąg.

Problem polega na tym, że UserNameklucza można użyć tylko wtedy, gdy proces jest uruchamiany przez root. Można go uruchomić tylko jako root, jeśli plist jest własnością root. Zasadniczo proces jest uruchamiany przez rootowanie, a następnie suid'ed do określonego użytkownika. Jeśli chcesz, aby ten proces działał jak ty, umieść plist w folderze ~ / Library / LaunchAgents i usuń klucz UserName.


Działa po usunięciu opcji „Nazwa użytkownika” dla zabbix_agend. Dziękuję Ci! - gist.github.com/chusiang/04db38f5173784e33b68
Chu-Saing Lai

Dziwne… Nadal nie ładuje się po usunięciu nazwy „UserName”…
MetroWind

1

Czy próbowałeś ręcznie ponownie załadować agenta, który miał uprawnienia użytkownika? Nie do końca rozumiem, dlaczego to wszystko jest wymagane, ale uważam, że musisz być dołączony do domeny użytkowników (wydaje się, że nie jesteś przywiązany, gdy działasz jako root). Użycie tych funkcji do ponownego podłączenia działało dla mnie.

function as_user {
    local user="$1"
    local user_pid=$(ps -axj | awk "/^$user / {print \$2;exit}")
    local command="sudo launchctl bsexec $user_pid sudo -u '$user' $2"
    echo "Running:"
    echo "$command"
    eval $command
}

function as_current_user {
    as_user "$(whoami)" "$*"
}

function reload_agent {
    as_current_user launchctl unload "$1"
    as_current_user launchctl load "$1"
}

Użyłbyś tego w następujący sposób:

reload_agent ~/Library/LaunchAgents/com.hw.helloworld.plist

Bsexec ponownie umieści Cię w domenie i pozwoli Ci dodać zadanie jako program uruchamiający użytkownika.


Mówi: /Users/darksair/Library/LaunchAgents/retrmail.plist: Operacja już trwa. W tym momencie moje pytania są w zasadzie: dlaczego polecenie kickstart nie zadziałało? I dlaczego muszę ustawić własność plist na root…?
MetroWind

1
NIE należy ustawiać właściciela pliku plist na root; wszystko w ~ / Library / LaunchAgents powinno być własnością użytkownika, do którego należy ten katalog. Dostałem operację już trwającą, kiedy nie wyładowałem polecenia przed jego załadowaniem. Czy korzystasz z funkcji, którą zapewniłem?
imalison

Tak. Korzystałem z twoich funkcji. I najpierw rozładowałem plist…
MetroWind

Właśnie próbowałem załadować pierwszy plist, który podałeś, i zadziałało to dla mnie. Jakie uprawnienia są ustawione dla pliku?
imalison

To niesamowity kawałek kodu dla tak wielu rzeczy. Używam mieszanki marionetkowych i niestandardowych skryptów bash do zarządzania wieloma różnymi urządzeniami macOS, a przypadkowe problemy, ponieważ sesja audytu bezpieczeństwa lub domena użytkownika są nieprawidłowe, są tak powszechne. Świetna robota!
Andrew White
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.