Suivre


J'ai un pb avec une tâche cron qui fait un tar et qui est en pause depuis longtemps (plusieurs jours). J'imagine qu'elle attend une validation de la part de l'utilisateur et j'aimerais bien savoir laquelle.
Y a-t-il un moyen de voir la sortie d'un process qui est en cours sans l'arrêter ? Un truc du style :

cat /proc/[id]/le-bon-fichier

ou :

ps --la-bonne-option [id] ?

Merci pour votre aide

· · Web · 4 · 3 · 1

@jpfox je n’ai pas la solution, mais je tenterai bien un lsof -p $PID pour trouver les sorties STDERR et STDOUT du process. (en admettant que ça marche)

@oldsysops @jpfox En plus de ça, tu peux reptyr ?

Sur un coup de bol, ça va échanger le terminal de ton process.
Ceci dit tu auras quand même perdu la sortie d'avant.
Sur un coup de bol, kill -HUP relancera un peu de parlotte (mais ça peut aussi tuer le process...)

@jpfox @ffeth
sinon lancer le process cron en screen/tmux et se ratacher a celui-ci le matin pour voir le debug...

@oldsysops @ffeth
argh, j'ai tué mon process avec un kill HUP... merci quand même pour les astuces

@jpfox note: avec les timers systemd bien configurés tu ne perdras plus le log

@oldsysops

@ffeth @jpfox
les timers systemd ?
Je ne connais pas tu as un lien pour plus tard ?

@oldsysops ça peut être configuré par l'utilisateur ou sur le système, ce sont des unit toutes simples

wiki.archlinux.org/title/Syste
@jpfox

@oldsysops
J'ai bien un fichier de log en sortie mais celui-ci contient un warning au lancement de la commande tar (normal vu mon appel) mais pas la question qui est posé à l'utilisateur.

paste.jpfox.fr/?52eef269cd7a48

@jpfox @oldsysops à moins d'avoir installé ttysnoop avant j'en doute…
Ou alors il faudrait attacher gdb au processus (on peut continuer en quittant), et chercher dans l'espace d'adressage s'il reste des choses…

@jpfox D'expérience tar n'attend pas de validation utilisateur (après ça peut dépendre des options qu'on lui passe).
Est-ce que dans la liste des processus (ps faux, htop), le process tar est en statut R ou S ?
Dans /proc/[pid]/fd tu peux voir les descripteurs de fichiers utilisés, notamment 1 (stdout) et 2 (stderr), par défaut cron sauvegarde ces informations pour envoyer un mail avec leur contenu (sauf si >/dev/null dans la crontab).
Tu peux aussi regarder la date du fichier tar

@fulax argh, j'ai tué mon process avec un kill HUP... merci quand même pour les astuces

@jpfox

tail -f /proc/<ton_pid>/fd/1
Ou strace -p ton_pid -s 9999 -e trace=write

Selon ce que fait ton process, le second donnera plus d'infos puisque l'appel systeme write ne concerne évidemment pas que la sortie standard.

@devnull
argh, j'ai tué mon process avec un kill HUP... merci quand même pour les astuces

@jpfox Mais l'idéal pour un cron job, quand même, ça reste de logger ce qu'il fait dans un fichier. Mais bon, ça ce se fais au moment d'écrire le cronjob.

@devnull

Tu fais ça comment ?
J'avais tenté un borgbackup (mon tout premier) avec anacron sur le PC d'un parent, et ça n'a jamais marché...
Avoir le log ça serait effectivement utile.

@jpfox

@lienrag Une simple redirection (ne pas oublier la sortie d'erreur) vers un fichier¹ avec éventuellement un fichier par date indiquée dans le nom, si c'est commande « standard » qui crache sur les sorties d'erreur. Si c'est un script maison, directement utiliser le mécanisme de log/bibliothèque qui va bien, du langage utiliser.

--
1. Quand on utilise syslog. Je sais pas si systemd/journalctl rajoute un mécanisme de log a cron, utilisable autrement.

@jpfox

@devnull la sortie était bien logué, mais à part un warning non bloquant, rien de particulier dans le fichier de log

paste.jpfox.fr/?52eef269cd7a48

@jpfox Bizzare, s'il avait demandé une intervention de l'utilisateur, ça se serai vu dans les logs. Et à part peut-être les options spécifiques, je me souvent pas que tar en demande de toute façon.

Il aurai aussi évidemment gueuler si problème d'espace ou de permission. Je me demande ce qui pu merdes. Pas merci pour le casse-tête matinal 🤣

@devnull surtout que ce traitement marchait sans pb depuis des années... il s'agit d'un tar fait par backup-manager.
ça va retourner ce soir, je verrai ce que ça donne.
merci en tout cas

@whilelm Oui, rien changé, le backup suivant s'est bien passé

@jpfox d'après mon expérience, je dirais non.
Tu dois traiter le entrées avant de lancer la tâche.
Pour débuger, envoie les sorties vers un fichier log.

Inscrivez-vous pour prendre part à la conversation
Mastodon G3L

Instance de l'association G3L basée à Valence, Drôme, France