Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**Last issue we covered more settings and why I like to add byobu to the mix. My proofreader friend asked me why I don’t continue and do an overview of terminator. I mean if I have to cover terminator and tilix I will, but I feel that, if I do, we are moving laterally and not towards my goal of getting done before Christmas... :) Instead of me heading down that road, I’d rather ask our readers if they would like an article on Terminator and Tilix. I mean we have done an article on Wezterm before, but it was more of a “make wezterm your own” sort of article. I can make it separate and not part of command-and-conquer, as I want us to do more “command” on here and less applications. We were looking at foreground and background processes and command chains, which is fundamental. We ran through a bunch of commands in the beginning and I want to return there. 

When we run our commands or scripts, they become processes in the shell. We can see what processes we have running with the “ps” command.

If we look at this screenshot (below), we can see that I have a terminal open and I am running btop and I ran ps. If you want to see which process launched which process, you need to append “f” (so ps -af ; not to be confused with F!). This is not live though; it is a snapshot of what was running when I hit enter. If you hit the ps man page, it will tell you that it accepts unix style options with one dash, BSD style options with no dash, and gnu style with double-dashes. Meaning “almost” anything goes, you can type ps aux or ps -aux and it will work. As a newbie, just remember, this is not the case in other Linux commands. In my early days of using Linux, the only way I knew to get the environment variables was with ps. If you have no idea what I’m talking about, then in your terminal, type: ps e**

Dans le dernier numéro, nous avons abordé davantage de paramètres et expliqué pourquoi j'aime ajouter byobu. Mon ami relecteur m'a demandé pourquoi je ne continuais pas et ne faisais pas une présentation de Terminator. Si je dois aborder Terminator et Tilix, je le ferai, mais j'ai l'impression que, si je le faisais, nous nous égarerions et n'atteindrions pas mon objectif de terminer avant Noël… :) Au lieu de m'engager dans cette voie, je préfère demander à nos lecteurs s'ils souhaitent un article sur Terminator et Tilix. Nous avons déjà publié un article sur Wezterm, mais il s'agissait plutôt d'un article « appropriez-vous Wezterm ». Je peux le publier séparément et l'exclure de Command-and-Conquer, car je souhaite que nous utilisions davantage de « commandes » ici et moins d'applications. Nous avons étudié les processus d'avant-plan et d'arrière-plan et les chaînes de commandes, ce qui est fondamental. Nous avons parcouru plusieurs commandes au début et je souhaite y revenir.

Lorsque nous exécutons nos commandes ou nos scripts, ils deviennent des processus dans le shell. Nous pouvons voir les processus en cours d'exécution avec la commande « ps ».

La capture d'écran ci-dessous montre un terminal ouvert, avec btop et ps lancés. Pour savoir quel processus a lancé quel processus, il faut ajouter « f » (donc ps -af ; à ne pas confondre avec F !). Ce n'est cependant pas une commande en temps réel ; il s'agit d'un instantané de ce qui était en cours d'exécution lorsque j'ai appuyé sur Entrée. Si vous consultez la page de manuel de ps, vous verrez qu'elle accepte les options de style Unix avec un tiret, les options de style BSD sans tiret et le style GNU avec deux tirets. Autrement dit, presque tout est possible : vous pouvez taper ps aux ou ps -aux et cela fonctionnera. En tant que débutant, rappelez-vous que ce n'est pas le cas avec les autres commandes Linux. À mes débuts sous Linux, la seule façon que je connaissais pour obtenir les variables d'environnement était d'utiliser ps. Si vous ne voyez pas de quoi je parle, tapez : ps e dans votre terminal.


**Do not file this away as not helpful; for instance, in the latest MacOS, they have hidden the sandboxd process from the process viewer. (It is what makes older Mac’s slow as treacle flowing down the road as it uses 100% CPU on one of your cores and also heating it up and getting it to choke.) So the only way to kill it now, is to go and find the process ID and kill it in the terminal.

I’m using btop as an example here, but this would be how one would look for the sandboxd process on a Mac, as it is more-or-less the same. I like the “top” derivatives, like htop, btop, etc, as they are live. This does not mean that we cannot get the same information via ps. Though this is a bit convoluted, I can show you how. 

I just took the top 5 here, but you can clearly see that my game, ADOM, is at the beginning, that corresponds with btop. (I was just not fast enough in my image capture to show 18% CPU use as the game launched). The same goes for RAM, I can just choose column “6” instead.

The quickest way to find a PID I know of is via ‘pgrep’. Now that you know the long way (and the how), let me do it the short way. If I type: pgrep btop -I just get the PID back, nothing else. Try this yourself on one of your own processes. **

Ne le rangez pas en disant que c'est inutile ; par exemple, dans la dernière version de macOS, le processus sandboxd a été masqué dans l'afficheur de processus. (C'est ce qui ralentit les anciens Mac, car il utilise 100 % du processeur sur l'un de vos cœurs, le fait surchauffer et le fait suffoquer.) La seule façon de le tuer maintenant est de trouver l'ID du processus et de le tuer dans le terminal.

J'utilise btop comme exemple, mais voici comment on rechercherait le processus sandboxd sur un Mac, car il est plus ou moins le même. J'aime les dérivés « top », comme htop, btop, etc., car ils sont actifs. Cela ne signifie pas que nous ne pouvons pas obtenir les mêmes informations via ps. Bien que ce soit un peu compliqué, je peux vous montrer comment.

Je viens de prendre le top 5, mais vous pouvez clairement voir que mon jeu, ADOM, est au début, ce qui correspond à btop. (Je n'ai tout simplement pas été assez rapide dans ma capture d'image pour afficher une utilisation CPU de 18 % au lancement du jeu.) Il en va de même pour la RAM : je peux simplement choisir la colonne « 6 ».

Le moyen le plus rapide de trouver un PID que je connaisse est d'utiliser « pgrep ». Maintenant que vous connaissez la méthode longue (et comment), laissez-moi faire la méthode courte. Si je tape : pgrep btop -, je récupère simplement le PID, rien d'autre. Essayez cela vous-même sur l'un de vos propres processus.


**OK, once we find the culprit, we can kill it (stab-stab) No? The kill command actually sends a signal to a process. (It sounds a lot less exciting if you put it this way.) Remember we spoke about SIGHUP previously, that is a signal. If we use keyboard shortcuts, like CTRL+C or CTRL+D, it also just sends off a signal and they are numbered. The one we are interested in is SIGKILL with an ID of 9. (Should be 47... don’t you agree?).

I already know that my btop process has an PID of 2474920, as you can see in previous screenshots. I can now issue the kill command and give it ‘-9’ (SIGKILL) as my option, followed by the PID. That would be: kill -9 2474920

-And just like that, btop is gone. ‘Graceflly’ would be the: -15 (SIGTERM) option, but sometimes you just need violence, amiright?

I always go and look at the PID, just in case there is more than one process running, but if you are confident, you could use the ‘pkill’ command and simply type: pkill btop (SIGTERM by default). If you want to know the PID of the process that pkill just closed, you can specify the -e option. Maybe I’m living in a bubble, but I have never used any of the other options and I don’t think any of you other n00bs will, it is just usually easier with htop.**

OK, une fois le coupable trouvé, on peut le tuer (coup de poing). Non ? La commande kill envoie en fait un signal à un processus. (Cela paraît beaucoup moins excitant si vous le présentez ainsi.) Rappelez-vous que nous avons parlé de SIGHUP précédemment : c'est un signal. Si nous utilisons des raccourcis clavier, comme CTRL+C ou CTRL+D, cela envoie également un signal numéroté. Celui qui nous intéresse est SIGKILL avec un ID de 9. (Il devrait être 47… n'est-ce pas ?)

Je sais déjà que mon processus btop a un PID de 2474920, comme vous pouvez le voir dans les captures d'écran précédentes. Je peux maintenant exécuter la commande kill et lui donner « -9 » (SIGKILL) comme option, suivi du PID. Ce serait : kill -9 2474920

Et voilà, btop disparaît. « Graceflly » serait l'option : -15 (SIGTERM), mais parfois, il suffit d'être violent, n'est-ce pas ?

Je regarde toujours le PID, au cas où plusieurs processus seraient en cours d'exécution, mais si vous êtes sûr de vous, vous pouvez utiliser la commande « pkill » et simplement taper : pkill btop (SIGTERM par défaut). Si vous souhaitez connaître le PID du processus que pkill vient de fermer, vous pouvez spécifier l'option -e. Je vis peut-être dans un bulle, mais je n'ai jamais utilisé les autres options et je ne pense pas que vous, les novices, le feriez ; c'est généralement plus simple avec htop.


**But, as I said, in my previous example with the Mac, as the PID keeps changing, one would need to extract the PID before feeding it to the kill command if you were to script it. Now you see why it would be important. Running a script to kill a nasty process is quicker than manually finding and killing it each time. The one we did not talk about is killall. The reason *I like killall is not because video games made me violent, but I can use the -u option to specify a user name and kill only the processes that particular user owns. This is particularly handy on systems with a lot of users. If you are the only user of your system, you would probably not use this option. Killall can work like kill with a PID or like pkill with just the process name. So typing: killall btop -is acceptable.

There are lots of processes waiting to die. No, seriously, practice!

If you have any complaints about the violence, misc@fullcirclemagazine.org**

Mais, comme je l'ai dit dans mon exemple précédent avec Mac, comme le PID change constamment, il faudrait l'extraire avant de l'envoyer à la commande kill si vous deviez l'utiliser dans un script. Vous comprenez maintenant pourquoi c'est important. Exécuter un script pour tuer un processus malveillant est plus rapide que de le rechercher et de le tuer manuellement à chaque fois. Le processus dont nous n'avons pas parlé est killall. Si *j'aime killall, ce n'est pas parce que les jeux vidéo m'ont rendu violent, mais parce que je peux utiliser l'option -u pour spécifier un nom d'utilisateur et tuer uniquement les processus appartenant à cet utilisateur. C'est particulièrement pratique sur les systèmes avec beaucoup d'utilisateurs. Si vous êtes le seul utilisateur de votre système, vous n'utiliserez probablement pas cette option. Killall peut fonctionner comme kill avec un PID ou comme pkill avec juste le nom du processus. Donc, taper : killall btop - est acceptable.

Il y a beaucoup de processus qui attendent de mourir. Non, sérieusement, entraînez-vous !

Si vous avez des plaintes concernant la violence, veuillez contacter misc@fullcirclemagazine.org