• # reponse

    Posté par  . Évalué à 2. Dernière modification le 27 août 2019 à 18:39.

    ps -aux | grep "[n]om_processus"
    par exemple ps -aux | grep "[f]irefox"

    Si la commande n'affiche rien, c'est qu'il n'est pas listé dans les processus actif. Ne fonctionne pas avec les rootkit.

    Si non tu peux aussi lancer l’exécutable en ligne de commande et voir s'il te renvoie des erreurs voir forcer l'enregistrement des erreurs dans un fichiers en ajoutant 2> /tmp/erreurs.txt en fin de commande

    /home/$USER/ton_executable 2> /tmp/erreurs.txt && echo "je n'ai rien renvoyé comme erreur au shell" || echo "j'ai planté, va voir dans /tmp/erreurs.txt"

    • [^] # Re: reponse

      Posté par  . Évalué à 7.

      Ou plus simplement pgrep -laf <nom>.

      Sinon, qu’est-ce qu’on entend par planté ? Qui doit vérifier ça ?

      Parce que, par exemple, systemd ou Docker peuvent redémarrer automatiquement le processus en cas de code de sortie différent de 0 ou ce genre de chose.

      Si le but est de vérifier (en ayant le PID) que le process existe toujours, vérifier la présence de /proc/<pid> et vérifier que le processus n’est pas dans un état Z (zombie) ou T (stopped) dans /proc/<pid>/stat, pourrait aussi faire l’affaire.

      • [^] # Re: reponse

        Posté par  . Évalué à 2.

        ok je me suis mal exprimé.

        Je veux dire que le processus est bloqué par un dead lock. donc le processus est toujours actif mais il n'avance plus dans ses instructions

        • [^] # Re: reponse

          Posté par  . Évalué à 7.

          Ah oui coté formulation ça se pose là…

          le plus simple c'est d'y attacher un debbugger et voir où il est gdb --pid $(pidof monprocessus), puis pour voir où est le programme la commande bt.
          S'il est multi threade (il y de fortes chances vu que tu parles d'étreinte fatale), tu peux itérer sur les thread à l'aide de la commande thread; ou plus simple lancer la même commande sur tous les tread avec thread aplly all commande

          Et cerise sur le gâteau, tu peux même le faire en batch :

          gdb --pid $(pidof monPorgramme) --eval-command="thread apply all bt" --batch

          cela te permet de voir à un instant t où le programme se trouve.

          Cette manip peut aussi être utilisé pour voir où un programme passe beaucoup de temps (suffit de le lancer régulièrement et voir où on est) C'est loin d'être aussi précis que des timers un peu partout, mais ça fonctionne sans altérer le code et ne demande pas de mise en place de truc lourds.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: reponse

            Posté par  . Évalué à 1. Dernière modification le 28 août 2019 à 15:06.

            ok merci beaucoup pour l'info

          • [^] # Re: reponse

            Posté par  . Évalué à 2.

            Ah oui coté formulation ça se pose là…

            Tu es sévère, pour moi sa formulation de base m'a fait immédiatement pensé à un process "bloqué".

            Sinon, une autre méthode, moins fiable mais un chouia moins violente, c'est de surveiller l'évolution des fichiers /proc/<pid>/stat ou encore statm et io: tu dumpes dans un coin, tu attends X secondes, tu redumpes et tu compares: si ça diffère entre deux dumps, c'est qu'il se passe des choses. Sinon, c'est qu'il se passe rien.

            Ex:

            ~$ cat /proc/20783/stat > /tmp/1
            ~$ cat /proc/20783/stat > /tmp/2
            ~$ cat /proc/20783/stat > /tmp/3
            ~$ cat /proc/20783/stat > /tmp/4
            ~$ md5sum /tmp/[1-4]
            77bfb8fb645744baf6b2f230c21ed3ab /tmp/1
            77bfb8fb645744baf6b2f230c21ed3ab /tmp/2
            f9d987e43632b72f935a90b8532b163d /tmp/3
            f9d987e43632b72f935a90b8532b163d /tmp/4

            Après, le risque, c'est que si le soft en question idle (parce qu'en attente d'une entrée quelconque) tu risques de le croire, à tort, planté.

        • [^] # Re: reponse

          Posté par  . Évalué à 5.

          Tu peux essayer avec strace de voir les appels systèmes fait par ton programme.

          • [^] # Re: reponse

            Posté par  . Évalué à 2.

            Si il n'a pas accès aux sources, c'est potentiellement un soft proprio.

            Si c'est un soft proprio, il y a potentiellement des protections anti-debug qui empêcheront de l'executer via strace :-(

            • [^] # Re: reponse

              Posté par  . Évalué à 2.

              Je suis curieux. Qu’est-ce qui permettrait à un process de savoir qu’un autre process lit les syscall qu’il fait ?

              • [^] # Re: reponse

                Posté par  . Évalué à 2.

                strace tout comme gdb utilise ptrace() (manpage)

                strace permet à la fois de s'attacher à un processus pour en inspecter l'execution et de savoir, en tant que process si un autre est attaché.

                Ce pdf semble au premier coup d'oeil intéressant et synthétique pour ce sujet.

  • # Le mieux ...

    Posté par  . Évalué à 2.

    … reste de tester le fonctionnel, en fait.

    Si c'est un service réseau, connectes y toi et joue un bout du protocole qu'il implémente.
    Si c'est un service de traitement de fichier, vérifie que ses sorties sont réellement produites.
    Si c'est un service qui consomme/produit quoi que ce soit, trouve un moyen de te mettre entre la source ou la destination pour contrôler qu'il se passe quelque chose.

    Dans l'absolu, savoir si un processus est 100% opérant sans controler son travail ou modifier son code est plutôt ardu et les rares méthodes qui existeraient seront quoi qu'il arrive un gros bidouillage possiblement couteux en perf, en temps et pas nécessairement possible.
    En vrac: modules kernel pour contrôler au niveau du scheduler, hooks des symboles dynamiques utilisés par le binaire à coup de LD_PRELOAD, ptrace, gdb, strace, etc…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.