Forum Linux.débutant Création d’un script

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
29
nov.
2024

Bonjour,

je suis nouvelle sur ce forum car je viens de débuter une formation en Admin IT.

J’ai tenté de créer un script afin de démarrer un processus Zombie.

Avec la commande pas aux | grep Z je vois que le processus est en S+ mais quand je veux éliminer le zombie avec kill -9 il me dit no such process.

Quelqu’un peut m’aider svp?

J’utilise Debian via Virtualbox.

Merci à vous

  • # World War Z

    Posté par  . Évalué à 1 (+0/-0).

    Parce que tuer un enfant ne tue pas les parents?

    Peut-être pkill ou killall avec le nom du processus en paramètre!

    • [^] # Re: World War Z

      Posté par  . Évalué à 2 (+0/-0).

      si le processus parent et le processus enfant n'ont pas le même nom, pkill ne fonctionnera pas. Et en lisant la page man de killal, je ne suis pas sûr non plus que cette commande fonctionne :

      -w, --wait
    Attendre que tous les processus tués meurent. killall vérifiera une fois par seconde s'il existe encore un processus visé, et ne reviendra que lorsqu'il n'y en aura plus. Notez que killall peut attendre indéfiniment si le signal est ignoré, n'a pas d'effet ou si le processus reste à l'état zombie.

      • [^] # Re: World War Z

        Posté par  . Évalué à 1 (+0/-0).

        D’accord, mince… je n’avais pas pensé à ça!

        Sur des sites ils parlent de ppid pour obtenir le pid du parent(en espérant qu’il ne base pas sur le nom)

        Je teste pas, s’il y a des volontaires…

  • # c'est le propre des processus zombies ....

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 29 novembre 2024 à 16:42.

    ils ne peuvent être tués car ils ne sont ni vivants, ni complêtement morts, d'ou leur nom … :)

    Explications sur wikipedia

  • # zombie ≠ endormi

    Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

    Voici les codes d’état d’après un man ps en anglais :

    PROCESS STATE CODES
       Here are the different values that the s, stat and state output
       specifiers (header "STAT" or "S") will display to describe the state of
       a process.
       D    Uninterruptible sleep (usually IO)
       R    Running or runnable (on run queue)
       S    Interruptible sleep (waiting for an event to complete)
       T    Stopped, either by a job control signal or because it is being
            traced.
       W    paging (not valid since the 2.6.xx kernel)
       X    dead (should never be seen)
       Z    Defunct ("zombie") process, terminated but not reaped by its
            parent.

       For BSD formats and when the stat keyword is used, additional
       characters may be displayed:
       <    high-priority (not nice to other users)
       N    low-priority (nice to other users)
       L    has pages locked into memory (for real-time and custom IO)
       s    is a session leader
       l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
       +    is in the foreground process group

    Donc S indique que le processus est en attente que certaines opérations se terminent. C’est souvent l’attente d’une entrée/sortie (par exemple une réponse réseau, ou la lecture de données sur un disque occupé, ou juste une action de la personne devant le programme si celui-ci est interactif.) Du coup, si tu ne le trouves pas en voulant l'éliminer, c’est simplement que le processus a été exhaussé (i.e. eu ce qu’il attendait) et c’est terminé entre temps.
    Les principaux signaux sont expliqués par exemple sur https://www.baeldung.com/linux/process-states

    Nota : si tu n’es pas en train de faire un script portable (ce qui normalement te limiterait au ps POSIX), vu que tu es sous Debian (mais c’est présent dans la plupart des distributions GNU/Linux), tu peux remplacer ton ps aux | grep foo par pgrep foo Par contre je ne l’ai jamais utilisé pour chercher l’état≥

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Envoyer un commentaire

Suivre le flux des commentaires

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