Tag: process management

Generate A Process Tree

This shouldn’t be a very long (or complicated) article as we’re simply going to cover one way to generate a process tree. This is more useful than it may sound, especially in process management.

We’ll be doing this in distros that support apt. So, that’d be distros like Debian, Ubuntu, Linux Mint, Elementary, and many others. That’s distros within the Debian family. That’s a good chunk of the available distros, so this will apply to many of you.

It’s not that this won’t work on other distros. It’s that I haven’t tested this on other distros. You can likely follow along and figure it out with your package manager, I’ve just not done so. I do have a limited amount of time and the only human resource I have is myself. Man, I could use an editor!

For the record, this seems like something you’ll find installed by default on any major system. You may not need to install anything at all. This might just be already available.

Anyhow… About processes…

Everything running on Linux is a process. There are a whole lot of processes that make up a running system. For the most part, you can ignore all this and keep computing. However, when you troubleshoot a system you may be interested in which processes are running. If you’re recovering from a slow system, you may be interested in killing processes.

One process may spawn other processes. For example, you may have a browser with open tabs. The browser is itself one process. The open tabs may be separate processes. This is a good thing for things like compartmentalization and even security, but that’s outside of the scope of this article.

So, what tools will we be using?

psmisc:

I believe the correct term for psmisc is that it’s a meta-package. That is, psmisc is a package that contains some other tools. If you want to follow along with this article, that’s the package you’ll likely want to install. I’ll cover installing it with apt, which is nice.

If you’re interested in psmisc, here’s the psmisc project page. The package includes the following applications:

  • fuser – Identifies processes using files or sockets
  • killall – kills processes by name, e.g. killall -HUP named
  • prtstat – prints statistics of a process
  • pslog – prints log path(s) of a process
  • pstree – shows the currently running processes as a tree
  • peekfd – shows the data travelling [sic] over a file descriptor

Of these, we’re interested in ‘pstree’. We have mentioned the killall command before and chances are that you won’t need to install anything for this at all. I did mention that above…

pstree:

This is the tool we’ll be using to generate a process tree. It comes with the above package and is one of those tools I think is likely available by default. I’ll cover how to use apt to install it below, but it seems like one of those things that you’re going to find on other distros. You’ll likely find that it’s installed by default on all those distros.

You can verify that you have this available with the following command:

The output should match this:

Don’t worry if that’s not available, we’ll install it below.

If you want to generate a process tree, you’ll see that the man page confirms that this is a good tool to do so, though the name should have clued you in. To read the man page, just run this command:

See? It’s not all that involved. It’s a pretty simple application.

Generate A Process Tree:

To generate a process tree in Linux, you’ll need an open terminal. Well, if you’re going to use pstree to generate a process tree in Linux, you will need an open terminal. Most of you can just open a terminal by pressing CTRL + ALT + T on your keyboard.

With your terminal open, let’s make sure that you have installed psmisc.

Now that you have psmisc installed, you can use the pstree command. Don’t blame me for this, I didn’t do it. 

You can simply run the command as it stands:

However, I previously wrote this article:

How To: Kill Processes By Their PID (Process ID)

I want to tie into that article. You can use the pstree command, which is a nice and easily understood output, to show the PID. That command would look like this command:

However, there’s a more useful command for those dealing with sudden issues. You can use a flag known as --color=age to get an idea about how new the processes are.

Green would be within the past 60 seconds, yellow would be within the past hour – or so I’m told. Every time I try, it shows up red. You can try it if you want, like so:

Good luck with that one! Seriously… Good luck!

Even if that doesn’t work, you can now generate a process tree to show the running processes on your system. This seems like a good thing to know.

Closure:

I was recently asked if I was running out of ideas for articles and the answer I gave them was that I am not. There’s always something to write about, even if it’s just a simple task like generating a process tree. Ideally, these articles will stand as a solution for those with specific problems. This is one of those articles.

Don’t forget that you can sponsor an article!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Show Running Processes

Your Linux system will have a lot of things running and these things have their own process, so let’s learn how to show running processes in the Linux terminal. This is something that’s a bit more advanced than most regular desktop users will need, but it’s still worth knowing.

You may not realize it, but you have a whole lot of processes running. These processes are what makes your system work. Without them, you’d have no activity. There’s a lot you could learn about processes, such as how they’re not all owned by your user account and how they all have their own process identification number (known as a PID).

None of those things are important for today’s article.

Today, we’re just going to show running processes in the terminal. It’s not a very complicated thing – and I’ll show you a couple of things you can do with this exercise.

You won’t need to install anything. We’ll be using the ps command that is almost certainly installed by default.

The ps Command:

The ps command is exactly the tool we want to use. It’s used to show running processes, the goal of this very article. You can verify that ps is available (and it is, it has been around since the UNIX days as I recall) with this command:

If you check the man page, you’ll confirm that this is the right tool for the job:

ps – report a snapshot of the current processes.

This is pretty self-explanatory. We’ll be using that very command to show running processes on your Linux box. Well, I suppose this would also be valid for the other *NIX OSes, like BSD and probably MacOS. I don’t use those OSes, so I can’t confirm the availability of the ps command – but it’s pretty likely to be there and perform the same task.

Show Running Processes:

As I mentioned above, you’ll need an open terminal for this exercise. You can open your terminal from your application menu. You can usually just press CTRL + ALT + T and your terminal will open.

The ps command reads the files in the /proc directory and doesn’t need elevated permissions to run. Some of the processes will not be owned by you, so acting on this information may require elevated permissions.

With your terminal open, simply run the ps command in the terminal:

As you can see, that’s not a lot of running processes. It doesn’t show them all.

If you want to see all the running processes:

Or, if you want to really use the ps command to get a lot of information:

Now, you don’t always want that much information at once, so try this:

There are times when you’ll want to use the ps command for a purpose, such as finding the PID of an application that’s frozen. To do that, you can pipe it to grep and limit the output. For example:

There’s a lot more to the ps command, so check man ps for more information. This is just scratching the surface.

Closure:

Well, this ended up shorter than I expected. I don’t want to dive in too deep. The goal is just a quick overview, but I expected it to take longer to describe this stuff. Fortunately, it’s a fairly easy subject – on the surface. Dig into the man page and you’ll see there’s quite a bit more that you can do.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

How To: Kill Processes By Their PID (Process ID)

Today’s article is one my regulars will be expecting, as it is an article that teaches you how to kill processes by their PID (Process ID). This shouldn’t be a long or complicated article and I’d like to think a beginner can understand what it is that we’ll be doing.

If you aren’t familiar with a process PID, you should read the article that I wrote just so that I could write this article:

Find An Application’s Process ID (PID)

Seriously, if you’re at all unsure, read that article. You could even consider that article the first part of this article, except I didn’t want to make my article long. Besides, it’s quite likely I’ll be referring to PIDs in the future.

NOTE: The subject we’ll be approaching today can be quite complicated. In this case, there are all sorts of ways to kill processes. Because of this, we’ll just be covering a couple of very easy ways to kill processes by using their PID. 

Why would you want to do this? 

Well, like it or not, sometimes applications freeze and sometimes applications refuse to close. This is true on every operating system. It can (and probably will) happen. I just tried a pinball application last night and it refused to close. (I closed it using the GUI task manager, not via the PID. Shh!)

Why would you want to kill processes by their PID, especially when you can also ‘killall‘ processes by their name?

Sometimes, you have processes with names like this:

Instead of trying to close that with a command, it has a PID of its own and can be closed using that. It’s so much easier to use the PID for this that you might as well learn how to do it now. Again, it won’t be all that complicated. I’ll do what I can to explain just a couple of choices while we all safely ignore the many other options.

NOTE: This isn’t quite the article I intended to write, so there’s that. The people on the Linux.org forum will know what I mean. This is largely due to my horrible memory.

Kill Processes By Their PID:

Yeah, this is a terminal thing. As such, you’re going to need an open terminal. In most distros, you can just press CTRL + ALT + T and that should be enough to open up your default terminal emulator.

With your terminal now open, let’s have a look at the tool we’ll be using:

If you won’t want to look, the kill command describes itself like this:

kill – send a signal to a process

Handily enough, that’s what we’ll be doing. We’ll be sending a single to a process, specifically to kill the process. You can send other signals. You can send quite a few different signals. Enter this into your terminal:

But, we’re only going to concern ourselves with 9 and 15. Those are the only two we’re going to worry about today. The syntax of the kill command would look like this:

Of course, you’re going to need to know the PID. If you read the article linked in the beginning section, you’d know how to do that. But…

For the sake of this article, we’ll be using ‘shutter‘, as it’s a fine application.

So, if you didn’t read the article about finding an application’s PID, helpfully linked again, we can just use ‘pgrep’. If I run the command on my computer, I get:

So we can now see the PID for Shutter easily enough. (There are numerous ways to get an application’s PID. The pgrep application is generally pretty handy.)

The first command we’re going to try is asking the application to quit. We’re sending a command to the application and asking it nicely to die. That’s -15.

Using the PID gathered in the previous command, and knowing the proper syntax for this command, we end up with a command that looks like this:

Of course, sometimes the application doesn’t die when asked nicely. That’s not all that often, but it’s also not all that rare. It does happen and that’s when we skip trying to talk to the application and send a command straight to the kernel. That’d look like this:

That command tells the kernel to drop the application. In theory, this always works. You may still see the process listed in your list of processes but that’s just a zombie process and nothing to be too alarmed with.

You want to first try -15 because that closes the application more gracefully.  When you use -9 as your signal, you’re more or less just using a hammer to kill the process. If -9 doesn’t work, something is up with your kernel and it’s time to reboot. 

NOTE: The commands I used did not include ‘sudo‘. That’s because I owned the processes. If it’s a process owned by someone other than your user, you will need the correct permissions to kill it, such as sudo.

I am not going to cover them here, but you can send all sorts of signals with the kill command – not all of which kill the process. For more information, I highly recommend the following command (and then digging deeper into the rabbit hole):

I suspect you’ll find that to be more than enough information for one day, even though this article hopefully makes it so simple that a beginner can follow along. Hopefully…

Closure:

Well, there you have it. Here’s yet another article and this time we’ve learned how to kill processes by their PID. There’s so much more to this, but those are the basics. You can generally ignore the rest as an average user. You can also probably do a great deal of this with the task manager, all with a nice GUI. It’s worth knowing, and doubly so if you spend any time remotely connected to another device via SSH.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Find An Application’s Process ID (PID)

Today we’re going to have an article that’s straightforward and simple and it will be about how you find an applications’s process ID (PID). This isn’t the article I want to write. This is a case where I have to write one article so that I can write another article. Otherwise, we’d end up with a two-thousand-word article that nobody would read. 

Let’s start with the basics – and it is very, very basic…

Every process running on your Linux computer has a Process ID (PID from here on out). Each process has a unique PID. Curiously, not all PIDs are using resources. Some PIDs are sleeping. If you work at it and find the right dodgy application (I’m looking at you, Shutter), you can even find zombie processes that are darned near impossible to kill (which might be foreshadowing a future article).

Though, unlike the movies, zombie processes are perfectly okay. They just sit there consuming no resources. Plus, they don’t eat brains (or CPU power), nor do they devour human flesh. They don’t even spread to other processes. In fact, with all that information, maybe calling them zombie processes is a bad idea. It’s not my idea – and they do share one thing in common with zombies in that they can’t be killed. (Zombies are already dead. You can’t kill something that’s already dead!)

There are many ways to find the PID for any given process. You can probably crack open your system monitor and find quite a few listed right there. You won’t even need the terminal for that. Imagine that?!?

(Of course, we’ll be finding PIDs in the terminal. It’s just what we do.)

Find An Application’s PID:

Yup. We’ll need an open terminal. Chances are reasonably good that you can just press CTRL + ALT + T and open up a terminal. Give it a shot, if you haven’t already.

The first thing we’re going to do is generate a giant list of running processes. The first column will be who owns the process (not always you) and the second column will be the PID. To generate this giant list, try this command in said terminal:

It’s a pretty big list, isn’t it? Well, let’s use ‘grep’ to narrow that down quite a bit. You can pipe the output from the previous command into grep and that would look like this:

Using Shutter as an example, the command would look like this:

NOTE: You may find that you see multiple PIDs. That’s because there are multiple instances of the application running. 

If you know the name of the process, you can also try pidof (which should also indicate what it does – it tells you the PID of an application).

So, let’s say we wanted to know the PID of bash. That command would look like this:

In my case, I get four different numbers because I have multiple terminals open, each using bash. No, I don’t consider four open terminals to be abnormal. Well, at least it’s fairly normal for me.

Finally, chances are pretty good that you have ‘pgrep’ available. I did a flip through some VMs and it appears to be installed by default on all the distros I checked. You can use pgrep to find a PID. That would look like this:

So, using Shutter as an example again, we’d try something like this:

Now, not all processes seem to want to be listed like this. For example, if you run the ps aux command, you might have seen processes with weird names like this:

You go ahead and put that into pgrep and let me know if it works for you! It doesn’t work here. But, if you tried pgrep gvfs it will spit out some PIDs for you. At that point, you’re officially above my pay grade. I am not sure and I do not know everything. I did some searching, like a good 30 minutes worth of searching, and didn’t find anything conclusive.

If you happen to know what’s going on, let me know in the comments! Someone is always happy to let me know what I missed (and I’m so grateful for that, I really am.) I swear, I learn more from writing these silly things than you learn from reading them.

Closure:

Well, have you ever needed to know the PID? It’s a pretty useful thing to know, which I’ll cover in a future article. I didn’t want to write some giant 2000-word article only to have folks gloss over the important bits. Sure, it’d make a nice segue to the next article, but you know darned well that I’m unlikely to write the articles in order. I get bored easily!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Subscribe To Our Newsletter
Get notified when new articles are published! It's free and I won't send you any spam.
.
Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.