savoir si un script est lancé par launchd ou depuis le term.
14 réponses
unbewusst.sein
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd
ou depuis le term ?
mais comment ?
intérêt : redirection des messages de stdout vers fichier de log...
--
« Là où la vérité n'est pas libre,
la liberté n'est pas vraie. »
(Jacques Prévert)
merci beaucoup pour cette éloquente et diligente réponse ;-) -- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
patpro ~ patrick proniewski
In article <1jjom86.1v0r6q2142b1zgN%, (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd ou depuis le term ? mais comment ? intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de launchd (1 pour le launchd system, et un PID variable pour le launchd user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand", pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas fait de connexion récemment, j'ai :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. - 0 net.patpro.mysql ../..
82342 est le PID de mon launchd utilisateur, et on voit en face de "net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. 29251 - net.patpro.mysql ../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1jjom86.1v0r6q2142b1zgN%unbewusst.sein@google.com.invalid>,
unbewusst.sein@google.com.invalid (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd
ou depuis le term ?
mais comment ?
intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de
launchd (1 pour le launchd system, et un PID variable pour le launchd
user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist
chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand",
pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas
fait de connexion récemment, j'ai :
$ launchctl list
PID Status Label
../..
82342 - 0x1020d0.launchd
../..
- 0 net.patpro.mysql
../..
82342 est le PID de mon launchd utilisateur, et on voit en face de
"net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list
PID Status Label
../..
82342 - 0x1020d0.launchd
../..
29251 - net.patpro.mysql
../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé
via launchd tente de baver dans stdout, la sortie se fait en réalité
dans /var/log/system.log
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <1jjom86.1v0r6q2142b1zgN%, (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd ou depuis le term ? mais comment ? intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de launchd (1 pour le launchd system, et un PID variable pour le launchd user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand", pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas fait de connexion récemment, j'ai :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. - 0 net.patpro.mysql ../..
82342 est le PID de mon launchd utilisateur, et on voit en face de "net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. 29251 - net.patpro.mysql ../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Erwan David
patpro ~ patrick proniewski écrivait :
In article <1jjom86.1v0r6q2142b1zgN%, (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd ou depuis le term ? mais comment ? intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de launchd (1 pour le launchd system, et un PID variable pour le launchd user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand", pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas fait de connexion récemment, j'ai :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. - 0 net.patpro.mysql ../..
82342 est le PID de mon launchd utilisateur, et on voit en face de "net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. 29251 - net.patpro.mysql ../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
patpro
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du terminal si c'est dans un terminal.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait :
In article <1jjom86.1v0r6q2142b1zgN%unbewusst.sein@google.com.invalid>,
unbewusst.sein@google.com.invalid (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd
ou depuis le term ?
mais comment ?
intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de
launchd (1 pour le launchd system, et un PID variable pour le launchd
user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist
chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand",
pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas
fait de connexion récemment, j'ai :
$ launchctl list
PID Status Label
../..
82342 - 0x1020d0.launchd
../..
- 0 net.patpro.mysql
../..
82342 est le PID de mon launchd utilisateur, et on voit en face de
"net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list
PID Status Label
../..
82342 - 0x1020d0.launchd
../..
29251 - net.patpro.mysql
../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé
via launchd tente de baver dans stdout, la sortie se fait en réalité
dans /var/log/system.log
patpro
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du
terminal si c'est dans un terminal.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
In article <1jjom86.1v0r6q2142b1zgN%, (Une Bévue) wrote:
j'imagine qu'il y a moyen de savoir si un script est lancé par launchd ou depuis le term ? mais comment ? intérêt : redirection des messages de stdout vers fichier de log...
si c'est launchd qui lance le script, le PID du parent est le PID de launchd (1 pour le launchd system, et un PID variable pour le launchd user).
Tu peux aussi utiliser launchctl list, qui te donne la listes des plist chargé, et qui renseigne la colonne PID qui un plist est lancé.
Par exemple, j'ai un plist launchd qui crée un tunnel ssh "on demand", pour me permettre d'accéder à un serveur MySQL via ssh. Si je n'ai pas fait de connexion récemment, j'ai :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. - 0 net.patpro.mysql ../..
82342 est le PID de mon launchd utilisateur, et on voit en face de "net.patpro.mysql" que le PID est absent : le tunnel n'est pas ouvert.
Je fais une connexion qui utilise ce tunnel, et j'obtiens :
$ launchctl list PID Status Label ../.. 82342 - 0x1020d0.launchd ../.. 29251 - net.patpro.mysql ../..
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
patpro
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du terminal si c'est dans un terminal.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Patrick Stadelmann
In article , patpro ~ patrick proniewski wrote:
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
Oui, c'est ainsi par défaut. Je crois qu'on peut spécifier un autre fichier soit dans le .plist soit via launchctl.
Patrick -- Patrick Stadelmann
In article <patpro-A5CB3C.21322106062010@news-4.proxad.net>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé
via launchd tente de baver dans stdout, la sortie se fait en réalité
dans /var/log/system.log
Oui, c'est ainsi par défaut. Je crois qu'on peut spécifier un autre
fichier soit dans le .plist soit via launchctl.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
Oui, c'est ainsi par défaut. Je crois qu'on peut spécifier un autre fichier soit dans le .plist soit via launchctl.
Patrick -- Patrick Stadelmann
unbewusst.sein
patpro ~ patrick proniewski wrote:
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
oui, ok, je vois pour le pid. je préfère, plutôt que /var/log/system.log envoyer dans mon propre fichier...
-- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé
via launchd tente de baver dans stdout, la sortie se fait en réalité
dans /var/log/system.log
oui, ok, je vois pour le pid.
je préfère, plutôt que /var/log/system.log envoyer dans mon propre
fichier...
--
« Là où la vérité n'est pas libre,
la liberté n'est pas vraie. »
(Jacques Prévert)
Note que je te raconte tout ça, mais on s'en fout. Si un script lancé via launchd tente de baver dans stdout, la sortie se fait en réalité dans /var/log/system.log
oui, ok, je vois pour le pid. je préfère, plutôt que /var/log/system.log envoyer dans mon propre fichier...
-- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
unbewusst.sein
Erwan David wrote:
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du terminal si c'est dans un terminal.
oui, j'avais pensé à ça aussi, tester si le script est attaché à un tty; mais bon je ne sais pas comment faire, google devrait m'aider. -- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
Erwan David <erwan@rail.eu.org> wrote:
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du
terminal si c'est dans un terminal.
oui, j'avais pensé à ça aussi, tester si le script est attaché à un tty;
mais bon je ne sais pas comment faire, google devrait m'aider.
--
« Là où la vérité n'est pas libre,
la liberté n'est pas vraie. »
(Jacques Prévert)
Avec tty on doit aussi avoir un erreur par launchd, le nom interne du terminal si c'est dans un terminal.
oui, j'avais pensé à ça aussi, tester si le script est attaché à un tty; mais bon je ne sais pas comment faire, google devrait m'aider. -- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
unbewusst.sein
Patrick Stadelmann wrote:
Oui, c'est ainsi par défaut. Je crois qu'on peut spécifier un autre fichier soit dans le .plist soit via launchctl.
oui, moi j'ai ça, à la fin de mes plist "LaunchAgent" :
Je crois, ça doit être expliqué dans cette technote : http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html
Patrick -- Patrick Stadelmann
unbewusst.sein
Patrick Stadelmann wrote:
> donc en fait ça se fait tout seul (?)
Je crois, ça doit être expliqué dans cette technote : http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html
oui, merci, en fait ça confirme : #
You can supply a specific destination for stdout and stderr by setting the StandardOutPath and StandardErrorPath properties in your program's property list. #
autrement il faut utiliser ASL...
donc c'est assez simple, je pense ne rien avoir à faire d'autre que changer deux lignes de ma plist ))) -- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> donc en fait ça se fait tout seul (?)
Je crois, ça doit être expliqué dans cette technote :
http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html
oui, merci, en fait ça confirme :
#
You can supply a specific destination for stdout and stderr by setting
the StandardOutPath and StandardErrorPath properties in your program's
property list.
#
autrement il faut utiliser ASL...
donc c'est assez simple, je pense ne rien avoir à faire d'autre que
changer deux lignes de ma plist )))
--
« Là où la vérité n'est pas libre,
la liberté n'est pas vraie. »
(Jacques Prévert)
Je crois, ça doit être expliqué dans cette technote : http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html
oui, merci, en fait ça confirme : #
You can supply a specific destination for stdout and stderr by setting the StandardOutPath and StandardErrorPath properties in your program's property list. #
autrement il faut utiliser ASL...
donc c'est assez simple, je pense ne rien avoir à faire d'autre que changer deux lignes de ma plist ))) -- « Là où la vérité n'est pas libre, la liberté n'est pas vraie. » (Jacques Prévert)
