Process Management
This howto will explain how to manage your processes on a Linux shell. Some things are specific for Blinkenshell, but most information here is general for Linux/UNIX.
Contents
Listing processes
The basic command that you will use to list processes is ps, you can use it like this:
ps
This will list all processes in the current session. If you have another SSH session for example, you will not see those processes here.
To view all processes on the entire system, with a more complete listing, you can use this command:
ps -ef
On a normal Linux system you will probably see hundreds of processes (kernel helpers, daemons, background processes etc). On Blinkenshell however, you will only see your own processes (but this will include processes from your other SSH sessions). This is a privacy feature of Blinkenshell, so that you can't see what other users are doing.
-e - Select all processes.
-f - Full-format listing.
Use man ps to see a full list of arguments for ps.
You can also use the BSD-syntax to show processes, like this for example:
ps aux
This will give a bit more details than ps -ef.
Finding a specific process
If you have lots of processes running and want to find a particular one, you can "pipe" the output of ps to grep which will filter the output and only show the processes you are interested in. It can be used like this:
ps -ef | grep irssi
This way you will only see the lines where the string "irssi" is included. Sometimes you will also get the actual grep process in the list.
Real-time process list
You can also get a real-time list of running processes with the command top. This will show all processes running on the system, with the ones using most CPU time at the top (you can however change the sort-key). Again, Blinkenshell will only show your own processes here.
top
At the top you will see some system-wide statistics, like uptime, load average, total tasks, memory and swap usage etc. Below is a list of the processes which will update every 2.0s per default.
You can change "Sort field" in top to show the processes using the most memory at the top instead. If you press O (capital O), you will get a list of fields you can sort on. Press q for "Resident size (kb)" and then press Enter. The sorting of the list will now change. Press h to view all hotkeys that can be used.
Exit by pressing q.
Reading the output
If you are new to Linux/UNIX the information from these commands might be a bit confusing. Here is a short explanation of some of the common fields:
- UID/USER - Your user ID, this will show your username or the numerical ID if your username is too long.
- PID - Process ID, an ID to distinguish a particular process.
- PPID - Parent Process ID, the process who "forked" (started) this process.
- STIME - The time when this process was first started.
- TTY - "teletypewriter", usually a PTS which is a virtual terminal (identifies a SSH session).
- TIME - How much CPU time this process has been using in total since it started.
- CMD/COMMAND - What command was used to start this process.
- VIRT/VSZ - Virtual memory size of the process in KiB.
- RSS - Resident Set Size, the non-swapped physical memory that a task has used in KiB.
- S/STAT - Process state. (see below).
Process states
The process state is usually a capital letter like S that will be shown in top or ps aux for example, it tells you what state the process is currently in. These are the commonly seen process states on a Linux box:
- 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.
- Z - Defunct ("zombie") process, terminated but not reaped by its parent.
Your process will mostly be in the S-state, which means they are running but not doing anything particular at the moment. If the process is currently doing something, it will be in the R-state.
If you have a process in the T-state, it has been totally stopped and is not running. You can read more about this in the background section. You will normally never see a process in the D or Z states for more than a very short period of time. If processes are in these states for a long period of time, you probably have some issue (overloaded machine, bugs).
Stopping processes
If you want to stop a process/program, the best way is always to use the built-in function. Text editors usually have something like ctrl-x (nano), :q (vi/vim), ctrl-x c (emacs) etc. You can use /quit in irssi and so on. Other programs might be interrupted with the default interrupt key: Ctrl-C (very useful).
If however some process has stopped responding, or is suspended to the background where you can't resume it, you can use the command kill to stop it. Start by listing your processes (ps aux for example), identify the process you want to kill and copy the Process ID (PID). Next, you can use this process ID to kill the process (to kill process ID 1234 in this example):
kill 1234
List your processes again to make sure it's gone.
Signals
kill will per default send the TERM signal to a process when you want to stop it. Sometimes the process is in a state where it can not respond to this signal (malfunctioning or suspended process etc), then you have to send the KILL signal to stop it. You can do this like so:
kill -9 1234
There are also other signals you can send (man kill), daemons/servers sometimes use the SIGHUP signal to reload the configuration for example.
Background processes
You can send processes to the background if it's something that you want to keep running, while using the terminal for something else. Be careful to not forget about your background processes however, they will still use up resources.
You should not use these commands for something like running your IRC/IM/Mail client in the background, use Screen for that since you want to be able to log out and then resume the program from another SSH session.
Background commands can be used to start a server program on an IRC bot in the background for example (Bots etc are only allowed on Supporter accounts however). You can use something like this:
eggdrop &
The & at the end will make this program run in the background. You can view the currently runninging background processes in the current session with the command jobs. Commands like ps aux will also show the process.
You can also suspend/pause a program you are currently running with the hotkey Ctrl-z. You can then send the program to the background with bg, or resume it again with fg. If you accidentaly hit Ctrl-z and want to resume it again, just remember to type fg.
Memory usage
On a normal Linux system, you can view the system wide memory usage with the command free -m and you're free to use all that available memory. On Blinkenshell however, you have a small slice of the total available memory to use for your processes. This is so that one user will not use up all available resources and deny others from using the shell.
On Blinkenshell, use can use this command to show your memory usage and limits:
showmem
A normal user has a limit of 128 MB RSS memory (and an additional 16 MB of swap). Your processes can however allocate up to 256 MB virtual memory (VIRT/VSZ in ps).
You can view the memory usage of each process with ps aux or similar (see "Listing processes").
You should not use more than about 80% of this memory allocation, or things might get very slow. Just like a normal desktop computer would if you were using almost all available memory. If the value "fail-count" in showmem shows anything more than 0, your processes has tried to allocate more than their allowed share. Your processes will start getting killed by the system if you use up all memory and swap.
A normal irssi process connected to a couple of IRC networks and with a few scripts loaded normally uses about 5-15 MB RSS memory. If your process is using much more than that, chances are that some script your are using is not very optimized or is leaking memory. Try restarting your IRC client with no scripts loaded, and then load them one by one and check the memory usage a while after loading each script to identify which one is using too much memory. It might also be that some buffer/log setting is too high.