are two ways you could send it a SIGHUP signal:
# kill -1 1833 # killall -HUP gnome-shell
Using killall to signal processes by name
With the killall command, you can signal processes by name instead of by process ID. The advantage is that you don't have to look up the process ID of the process that you want to kill. The potential downside is that you can kill more processes than you mean to if you are not careful. (For example, typing killall bash may kill a bunch of shells that you don't mean to kill.)
Like the kill command, killall uses SIGTERM (signal 15) if you don't explicitly enter a signal number. Also as with kill, you can send any signal you like to the process you name with killall. For example, if you see a process called testme running on your system and you want to kill it, you can simply enter the following:
$ killall -9 testme
The killall command can be particularly useful if you want to kill a bunch of commands of the same name.
Setting processor priority with nice and renice
When the Linux kernel tries to decide which running processes get access to the CPUs on your system, one of the things it takes into account is the nice value set on the process. Every process running on your system has a nice value between –20 and 19. By default, the nice value is set to 0. Here are a few facts about nice values:
The lower the nice value, the more access to the CPUs the process has. In other words, the nicer a process is, the less CPU attention it gets. So, a –20 nice value gets more attention than a process with a 19 nice value.
A regular user can set nice values only from 0 to 19. No negative values are allowed. So a regular user can't ask for a value that gives a process more attention than most processes get by default.
A regular user can set the nice value higher, not lower. So, for example, if a user sets the nice value on a process to 10 and then later wants to set it back to 5, that action will fail. Likewise, any attempt to set a negative value will fail.
A regular user can set the nice value only on the user's own processes.
The root user can set the nice value on any process to any valid value, up or down.
You can use the nice command to run a command with a particular nice value. When a process is running, you can change the nice value using the renice command, along with the process ID of the process, as in the example that follows:
# nice -n +5 updatedb &
The updatedb command is used to generate the locate database manually by gathering names of files throughout the filesystem. In this case, I just wanted updatedb to run in the background (&) and not interrupt work being done by other processes on the system. I ran the top command to make sure that the nice value was set properly:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20284 root 25 5 98.7m 932 644 D 2.7 0.0 0:00.96 updatedb
Notice that under the NI column, the nice value is set to 5. Because the command was run as the root user, the root user can lower the nice value later by using the renice command. (Remember that a regular user can't reduce the nice value or ever set it to a negative number.) Here's how you would change the nice value for the updatedb command just run to –5:
# renice -n -5 20284
If you ran the top command again, you might notice that the updatedb command is now at or near the top of the list of processes consuming CPU time because you gave it priority to get more CPU attention.
Limiting Processes with cgroups
You can use a feature like “nice” to give a single process more or less access to CPU time. Setting the nice value for one process, however, doesn't apply to child processes that a process might start up or any other related processes that are part of a larger service. In other words, “nice” doesn't limit the total amount of resources a particular user or application can consume from a Linux system.
As cloud computing takes hold, many Linux systems will be used more as hypervisors than as general-purpose computers. Their memory, processing power, and access to storage will become commodities to be shared by many users. In that model, more needs to be done to control the amount of system resources to which a particular user, application, container, or virtual machine running on a Linux system has access.
That's where cgroups come in.
Cgroups can be used to identify a process as a task, belonging to a particular control group. Tasks can be set up in a hierarchy where, for example, there may be a task called daemons that sets default limitations for all daemon server processes, then subtasks that may set specific limits on a web server daemon (httpd) for FTP service daemon (vsftpd).
As a task launches a process, other processes that the initial process launches (called child processes) inherit the limitations set for the parent process. Those limitations might say that all the processes in a control group only have access to particular processors and certain sets of RAM. Or they may only allow access to up to 30 percent of the total processing power of a machine.
The types of resources that can be limited by cgroups include the following:
Storage (blkio): Limits total input and output access to storage devices (such as hard disks, USB drives, and so on).
Processor scheduling (cpu): Assigns the amount of access a cgroup has to be scheduled for processing power.
Process accounting (cpuacct): Reports on CPU usage. This information can be leveraged to charge clients for the amount of processing power they use.
CPU assignment (cpuset): On systems with multiple CPU cores, assigns a task to a particular set of processors and associated memory.
Device access (devices): Allows tasks in a cgroup to open or create (mknod) selected device types.
Suspend/resume (freezer): Suspends and resumes cgroup tasks.
Memory usage (memory): Limits memory usage by task. It also creates reports on memory resources used.
Network bandwidth (net_cls): Limits network access to selected cgroup tasks. This is done by tagging network packets to identify the cgroup task that originated the packet and having the Linux traffic controller monitor and restrict packets coming from each cgroup.
Network traffic (net_prio): Sets priorities of network traffic coming from selected cgroups and lets administrators change these priorities on the fly.
Name spaces (ns): Separates cgroups into namespaces, so processes in one cgroup can only see the namespaces associated with the cgroup. Namespaces can include separate process tables, mount tables, and network interfaces.
