Comment activer le journal de launchd sur OS X 10.6 ?
J'ai ajouté un nouveau démon qui ne démarre pas correctement (le statut est 1).
Je veux déboguer le problème mais je n'ai pas pu trouver les journaux de launchd, ils ne sont pas dans /var/log/launchd.log.
En supposant que vous essayiez de journaliser votre processus plutôt que launchd lui-même, si vous incluez les lignes suivantes dans le fichier plist de launchd:
StandardOutPath
/chemin/vers/fichier_journal.log
StandardErrorPath
/chemin/vers/autre_fichier_journal.loget rechargez le processus, tout journal ou impression que vous avez interne à votre script sera capturé dans l'un de ces deux fichiers chaque fois qu'il sera exécuté. bien que la rotation des fichiers semble être à votre charge. comme vous pourriez vous y attendre, si vous utilisez le même fichier dans les deux cas, il enregistrera à la fois les erreurs et stdout au même endroit.
Voir : Section Débogage des travaux launchd dans la création de démons et agents.
Je me suis rendu compte que cet OS nécessite des droits d'administrateur, comme tout le reste. J'étais complètement à la recherche de cela après une journée à crier "WTF où se trouve le drapeau verbeux !" OSX est génial, c'est sûr, mais difficile à maîtriser. Merci +1
J'ai eu des problèmes avec mes serveurs Leopard et je pensais qu'il y avait quelque chose de mal avec mon launchd plist (même si le même plist fonctionne dans Snow Leopard). Il s'est avéré que j'ai trouvé ceci et ça marche comme un charme :)
Sous OS X 10.11 (El Capitan), vous pouvez utiliser sudo launchctl debug --stdout --stderr pour activer la journalisation ponctuelle, si vous ne souhaitez pas suivre l'option du système de fichiers suggérée par @peter.
Beaucoup de choses sont différentes dans l'implémentation actuelle de launchctl, et le est plutôt étrange. Par exemple, supposons que j'ai un service local que je configure à ~/Library/LaunchAgents/dev.localmon.plist, qui a l'étiquette dev.localmon. Son est gui/$UID/dev.localmon, où $UID est votre identifiant utilisateur, que votre terminal interprétera pour vous.
Donc en supposant que mon service dev.localmon plantait au démarrage (ce qu'il faisait), je pourrais appeler la commande suivante pour avoir launchctl rediriger la sortie standard et d'erreur du processus dans mon terminal la prochaine fois (et seulement la prochaine fois) que le service démarre :
sudo launchctl debug gui/$UID/dev.localmon --stdout --stderrComme cela bloque avec les TTYs ouverts et prêts, allez dans un autre terminal et exécutez :
launchctl start dev.localmon
# start est une commande héritée et n'utilise pas la nouvelle notation de service cibleEnsuite, de retour dans le premier terminal, vous devriez voir la sortie. (De manière étrange, elle ne se ferme pas lorsque le processus du service se termine, vous devrez donc faire Ctrl-C.)
Au fait, une fois que vous avez corrigé votre fichier de configuration avec n'importe quel chemin d'accès ou environnement qui cassait le service auparavant, vous devrez toujours utiliser l'ancienne commande launchctl unload ~/Library/LaunchAgents/dev.localmon.plist && launchctl load ~/Library/LaunchAgents/dev.localmon.plist en deux étapes car la sous-commande uncache prétendue de la documentation a l'effet suivant :
Commande n'est pas encore implémentée.
Houra pour la stratégie de sortie post-Jobs d'Apple : "Avancer rapidement et casser des choses"
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
