J'ai laissé un script en cours d'exécution sur une machine distante depuis que j'y travaillais localement. Je peux me connecter via SSH à la machine en tant que même utilisateur et voir le script s'exécuter ps
.
$ ps aux | grep ipcheck
myuser 18386 0.0 0.0 18460 3476 pts/0 S+ Dec14 1:11 /bin/bash ./ipchecker.sh
Il s'agit simplement de sortir sur stdout sur une session locale (je courais depuis ./ipchecker.sh
une fenêtre de terminal locale, pas de redirection, pas d'utilisation de screen
etc.).
Y at-il quand même une session SSH que je peux voir le résultat de cette commande en cours d’exécution (sans l’arrêter)?
Jusqu'ici, le mieux que j'ai trouvé est d'utiliser, strace -p 18386
mais je reçois des hordes de texte qui volent à l'écran, c'est beaucoup trop détaillé. Je peux m'arrêter strace
et passer au crible le résultat et trouver le texte importé sur la sortie standard, mais il est très long et déroutant. Évidemment, tant qu'il sera arrêté, je risque de rater quelque chose. J'aimerais trouver un moyen de voir la sortie du script en direct comme si je travaillais localement.
Quelqu'un peut-il améliorer cela? La réponse évidente est de redémarrer le script avec la redirection ou dans une screen
session, etc., ce n'est pas un script essentiel à la mission, donc je pourrais le faire. Plutôt, je vois cela comme un exercice d'apprentissage amusant.
la source
strace -p 4232 -e write
Réponses:
Si tout ce que vous voulez, c'est espionner le processus existant, vous pouvez utiliser
strace -p1234 -s9999 -e write
1234 comme ID de processus. (-s9999
évite que les chaînes ne soient tronquées à 32 caractères et quewrite
l'appel système produise une sortie.) Si vous souhaitez afficher uniquement les données écrites sur un descripteur de fichier particulier, vous pouvez utiliser quelque chose de similairestrace -p1234 -e trace= -e write=3
pour ne voir que les données écrites sur le descripteur de fichier 3 (-e trace=
empêche le système les appels d’être enregistrés). Cela ne vous donnera pas de sortie déjà produite.Si la sortie défile trop rapidement, vous pouvez la diriger vers un pageur tel que
less
, ou l'envoyer dans un fichier avecstrace -o trace.log …
.Avec de nombreux programmes, vous pouvez rediriger la sortie suivante avec un hack ptrace, vers votre terminal actuel ou vers une nouvelle session écran. Voir Comment puis-je désavouer un processus en cours et l'associer à un nouveau shell d'écran? et d'autres threads liés.
Notez que, selon la configuration de votre système, vous devrez peut-être exécuter toutes ces
strace
commandes en tant que root, même si le processus s'exécute sous votre utilisateur, sans privilèges supplémentaires. (Si le processus s'exécute en tant qu'utilisateur différent ou est setuid ou setgid, vous devrez vous lancer enstrace
tant qu'utilisateur root.) La plupart des distributions n'autorisent qu'un processus à retracer ses enfants (cela offre un avantage modéré en matière de sécurité: cela empêche toute injection directe de malware, mais n'empêche pas l'injection indirecte en modifiant les fichiers). Ceci est contrôlé par lekernel.yama.ptrace_scome
sysctl.la source
man strace
Vous pouvez accéder à la sortie via le
proc
système de fichiers.1
= stdout,2
= stderrla source
/dev/null
) - cela ne fonctionnera que si la sortie est redirigée vers un fichier.ping google.es
et dans une autre en tant que root:tail -f /proc/`pgrep ping`/fd/2
et rien n'est affiché.Dans BSD, vous pouvez utiliser la
watch
recherche d’un tty donné, par exempleSous Linux, cela ne sera pas possible si le processus n'a pas été exécuté sous multiplexeur auparavant, tel que
screen
outmux
. Voir aussi: Reptyr: Attacher un processus en cours à un nouveau terminalIl semble que le seul moyen est de déboguer le processus (par exemple
strace
,dtrace
/dtruss
,gdb
,lldb
, etc.).Puisque vous avez utilisé
strace
, pour extraire toute sortie significative, vous devez filtrer par une expression qualificative (telle quefile
), puis analyser la sortie. Voici un exemple:Cela permet d’imprimer l’opération d’écriture du processus (longueur de 1 000) spécifiée par PID (utilisée
pgrep
pour le trouver par son nom), de rediriger l’erreur standard vers la sortie (à filtrer) et d’imprimer la chaîne entre guillemets.Si vous utilisez une sortie binaire, vous pouvez analyser les caractères des séquences d'échappement en utilisant
read
(avec-r
) etprintf
(avec%b
), par exempleVérifiez
help read
davantage de paramètres (par exemple,-n
pour imprimer après un certain nombre de caractères plutôt que de nouvelle ligne).Voici un exemple plus complet:
Pour des exemples utilisant n’importe quel processus, veuillez vérifier: Comment analyser strace dans shell en texte brut? à stackoverflow
la source
Vous pourrez peut-être jeter un coup d’œil à l’écran distant en utilisant
ssh localhost 'DISPLAY=:0.0 xwd -root' | xwud -scale
oùlocalhost
doivent être remplacés vos identifiants de connexion au serveur distant et:0.0
avec le numéro d’affichage de votre interface graphique.Utilisez
x11vnc
, qui est un serveur VNC pour votre session X à l'écran.Lors de l'exécution sur l'une des 6 consoles virtuelles, essayez de
sudo setterm -dump 2 -file /dev/stdout
remplacer2
par le vc approprié.la source
Je conseillerais de créer un pipe nommé (
mkfifo
) et d'écrire dans ce fichier. Ensuite, lisez-le. Vous pouvez toujours le faire avec des choses commetail
, minimiser la sortie, etc. Chaque fois que vous effacez le tuyau (lisez-le), il est effacé, de sorte que la sortie n'est pas préservée.L’autre option serait d’écrire tout dans un fichier (un peu comme un fichier journal), puis de l’analyser à tout moment. Ce serait l'action recommandée si vous souhaitez conserver toutes les sorties.
la source
Vous pouvez toujours lancer un processus avec nohup et &
Ensuite, vous pourrez vérifier la progression de n'importe quel tty avec:
Cela fonctionne bien pour moi.
la source
Un moyen très simple d'obtenir la sortie serait de capturer votre sortie dans un fichier et de l'ajuster à la fin.
SI FAIRE: ./ipcheck
AU LIEU DE FAIRE: ./ipcheck> [remplacez votre nom de fichier]
Cela créerait un fichier de sortie où se trouve votre script. Ensuite, depuis n'importe quel autre shell bash, vous pouvez simplement mettre le fichier en file d'attente:
queue [remplacezvotre nom de fichier] -f
la source
setbuf(3)
), ce qui peut posertail
problème.Analyser la sortie de strace:
J'ai utilisé la réponse en haut (avec mon ID de processus de 28223) ...
Pour déterminer que je me soucie de
write(9
. (Le 9 est utilisé ci-dessous, il s'agit probablement d'un descripteur de fichier et peut être différent pour votre processus.) Ensuite, j'ai écrit un script Ruby rapide pour les analyser et les afficher.Coller ce qui suit dans
/usr/bin/parse_strace.rb
N'oublie pas
chmod a+x /usr/bin/parse_strace.rb
J'invoque
strace -xx
(sort hex, donc la regex correspond bien), en piping (y compris STDERR) à mon script avec9
comme premier argument.Et voila, il sort le STDOUT original du processus, les nouvelles lignes, la couleur et tout!
la source
vous ne pouvez pas obtenir l'ID de processus et communiquer avec lui avec USR1,
qui imprime le PID de votre script, puis l’utilisez pour
Je comprends que USR1 est un signal "défini par l'utilisateur", ce qui signifie que quiconque a créé le programme peut l'utiliser pour signifier "arrêter" ou "vider vos journaux" ou "imprimer des milliers de fois" ou peu importe.
la source