ce n'launchd statut 78 veux dire?? pourquoi mon agent utilisateur ne fonctionne pas??

Je veux courir à l'unisson le service de synchronisation de l'exécution en arrière-plan chaque fois que je me connecte. Mais le code de statut de mon agent est 78. Je ne sais pas pourquoi, j'ai essayé quelques corrigé en ligne, mais il ne fonctionne tout simplement pas.

Quel est le problème?? ci-dessous le fichier plist pour mon service.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>syncmyproject</string>
    <key>StandardOutPath</key>
    <string>/var/log/syncmyproject.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/syncmyproject.log</string>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>Debug</key>
    <true/>
    <key>EnableGlobbing</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/bin/unison</string>
      <string>-auto</string>
      <string>-batch</string>
      <string>-repeat watch</string>
      <string>~/home/project</string>
      <string>~/project</string>
    </array>
</dict>
</plist>
  • Vous pouvez grep ce fichier pour d'éventuels indices quant à ce qui est erroné: /var/log/system.log
InformationsquelleAutor Aaron Shen | 2015-12-11
  1. 37

    J'ai lu man launchctl, trouver 78 signifie function not implemented. Il ne l'aide pas beaucoup.

    Enfin je le faire fonctionner, en fait il y avait des erreurs dans le fichier plist, je vous recommande d'installer le brew cask install launchcontrol, qui est un outil graphique pour la launchctl, il peut aider à détecter les erreurs et les problèmes de prise de vue.

    • Merci pour cette. launchcontrol aidé à résoudre mon problème. Pour l'enregistrement, j'ai eu le statut de 78 et mon problème était que mon script n'a pas commencé avec un interprète, e,g; #!/bin/sh
    • Pour moi, le problème, c'est que le répertoire du journal n'était pas accessible par l'utilisateur actuel.
    • yep, moi aussi. J'ai eu une erreur dans l'arborescence. Cela fait qu'il est difficile à déboguer, car le script a fonctionné parfaitement quand je l'ai exécuté, mais pas quand launchd essayé de l'exécuter.
    • launchcontrol a été très utile! Il coûte de l'argent, mais la version d'essai peut encore déceler les erreurs, il ne peut pas enregistrer le nouveau fichier plist. Une question qui m'a surpris est que la sortie d'erreur standard de chemin d'accès a été défini sur un chemin qu'il ne pouvait pas écrire. LaunchControl surpris et l'a détectée alors que launchctl ne voulut jamais me donner existent code 78! Aussi ce site web, launchd.info, mais le LaunchControl personne a beaucoup de dépannage utiles info. Il sorte de bouchons LaunchControl dans quelques endroits, mais est également utile par lui-même.
    • Le problème dans mon cas, l'application a été ciblés n'ont pas les autorisations d'exécution
    • Une défaillance de WorkingDirectory peut provoquer un code d'état de 78 ainsi.
    • pour moi le problème a été clairement mentionné dans /var/log/system.journal que le script de l'autorisation est refusée. chmod 755 était suffisant pour faire fonctionner le tout. notez également que si quelque chose est ajouté au CHEMIN d'accès via un script personnalisé ajouté dans bashrc ou bash_profile qui n'est pas exécutée ainsi donc préférable de placer l'ensemble de votre CHEMIN EnvironmentVariables liste dans le fichier plist.

    InformationsquelleAutor Aaron Shen
  2. 6

    J'ai trouvé l'erreur a eu à faire avec des autorisations.
    J'ai essayé de rediriger les erreurs et les journaux de la /var/log répertoire qui mon utilisateur n'est pas en mesure d'écrire.
    Modification du chemin d'accès à quelque chose d'où mon utilisateur a des autorisations adéquates pour r+w, il fixe.

    Aussi, être prudent lors du chargement de votre LaunchAgents. Ne pas utiliser sudo pour charger un fichier plist si vous êtes dans le ~/Library/LaunchAgents répertoire.

    • Saint fume, qui a été mon erreur trop! Changer les logs vers un autre dossier fixe.
    • "Soyez prudent lors du chargement de votre LaunchAgents. Ne pas utiliser sudo pour charger un fichier plist si vous êtes dans le ~/Library/LaunchAgents répertoire." Oh mon saint chèvre. Ce... Vous êtes mon héros.
    InformationsquelleAutor Brian McCall
  3. 5

    [Couru dans ce problème, de sorte que la documentation de ce que j'ai trouvé]

    "78" est la dernière sortie du code du travail que vous êtes en cours d'exécution. De man launchctl:

    Sans arguments, la liste de tous les emplois chargé dans launchd dans trois
    les colonnes. La première colonne affiche le PID du travail si elle est en rodage
    ning. La deuxième colonne affiche la dernière sortie de statut de la poste. Si
    le nombre dans cette colonne est négatif, il représente le négatif de la
    le signal qui a cessé le travail. Ainsi, "-15" indiquent que l'
    de travail a été résilié avec SIGTERM. La troisième colonne est le travail de l'étiquette.
    Si [label] est spécifié, imprime des informations sur la demande de travail.

    I. e. vous avez besoin de lire la documentation (ou code source) pour le travail que vous êtes de départ. (Dans mon cas, mysqld)

    Il est intéressant de noter que "78" est mentionné comme un standard code de sortie sur Linux, indiquant une erreur de configuration. Afin de prendre un coup d'oeil à votre configuration de travail (et les journaux d'erreur?) pour voir si vous avez quelque chose de mal configuré.

    • dans mon cas, j'avais oublié de faire un chmod +x le script shell ':)
    • Dans mon cas, le journal de la coiffe (newsyslog) n'a pas été configuré pour restaurer l'ancien propriétaire de la stdout et stderr fichiers, en les rendant unwritable à l'utilisateur actuel.
    InformationsquelleAutor broofa
  4. 1

    Voici ce qui m'a surpris: Dans Mac OS X, vous pouvez exécuter des scripts shell de ligne de commande, même si il y a un "script" dans le fichier.
    Toutefois, lorsque vous exécutez de launchd vous avez à dire à quel binaire qui doit exécuter le script.
    A supposer que lorsque vous exécutez à partir de la ligne de commande, il utilise juste la coque actuelle (dans mon cas, bash), mais lors de l'exécution de launchd il n'y a pas de "autour de script".
    J'ai ajouté 

    #!/bin/sh

    la première ligne dans le fichier de script, et puis il a travaillé.

    InformationsquelleAutor Dan Bergh Johnsson
  5. 0

    Similaire à ci-dessus, j'ai été d'obtenir un statut 78 parce que j'avais lien symbolique dans mon chemin du script. La solution était d'utiliser le chemin absolu.

    InformationsquelleAutor Cephos
  6. -1

    J'ai eu cette erreur lors de l'exécution du mono pour démarrer un serveur web local. S'avère que la solution était de ne pas utiliser le mono chemin d'accès donné par "qui mono" (qui est un lien symbolique: /Library/Frameworks/Mono.framework/Versions/Current/Commands/mono), mais l'emplacement réel de l'exe (dans mon cas /Library/Frameworks/Mono.framework/Commands/mono).

    InformationsquelleAutor ra00l