CnC
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, 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
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.
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.
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.
Go out there and get your killing on; there are lots of processes waiting to die. No, seriously, practice!
If you have any complaints about the violence, misc@fullcirclemagazine.org