home > A computer > How to end a process in ubuntu. How to kill a process in Linux

How to end a process in ubuntu. How to kill a process in Linux

Signals are software interrupts. They are used for communication between processes in UNIX and UNIX-like operating systems such as Linux, Mac OS.

Signals have been in use since Bell Labs UNIX in the 1970s and are now formally defined by the POSIX standard. When a signal arrives at a process, the operating system interrupts the process's normal flow of execution and provides notification.

It doesn't matter which operating system you are using, you will surely encounter the fact that your applications get blocked and refuse to work properly. On Unix, Linux, there is a "kill" command that you can use to kill a process immediately, but not only that, but I'll talk about it a bit later. In this article “Kill command in Unix/Linux” I will tell and show various commands of the kill utility using ready-made examples.

kill commands and signals

When you issue the "kill" command, you are actually sending a signal to the system and instructing it to terminate the incorrect application robot. There are a total of 60 signals that can be used, but all you really need to know is SIGTERM(15) and SIGKILL(9).

You can view all signals with the command:

# kill -l

On my macOS:

I will try to talk about all the signals, but at the very beginning, let's talk only about the most important and frequently used ones.

Basic Signals

The following signals are part POSIX standard. Each signal is a macro defined in System header file. They are usually abbreviated without their SIG prefix; for example SIGHUP is often referred to simply as HUP.

SIGTERM– This signal requests the termination of a process that is running. This signal can be ignored. The process is given time to shut down nicely. When a program shuts down well, it means it has been given time to save its progress and free up resources. In other words, he didn't "forced" the termination of the process.

SIGKILL The SIGKILL signal causes the process to stop doing its work immediately. The program cannot ignore this signal. Unsaved progress will be lost.

Syntax for "kill".

The command syntax is:

# kill PID(s)

# kill [-s] [-l] %pid

The default signal (if not specified) is SIGTERM. When this signal does not help and does not work, you can use the following options for "kill" to force the process to terminate:

# kill SIGKILL PID

# kill -9 PID

where "-9" is the flag for the SIGKILL signal.

If you don't know which application PID to use to get rid of, then run the command:

$ ps -aux

And if you know a specific application (for example, apache), then you can weed out the unnecessary and display all processes for this service:

$ ps -aux | grep apache

And this will display all running applications along with its PID(s).

For example, to kill an application, I run the following command:

# kill -9 3629

It's also worth noting that you can run multiple processes at the same time so they can be "killed":

# kill -9 PID1 PID2 PID 3

Reboot configuration files or restart utilities:

# kill -1 number_of_PID

Particularly useful signals include HUP, INT, kill, STOP, CONT, and 0.

The options are:

-s signal_name
The symbolic name of a signal that specifies the signal to send a non-default signal to.

-l
If operand is not specified, then show signal names; AT otherwise, write the name of the signal corresponding to exit_status.

-signal_name
The symbolic name of a signal that specifies the signal to send to TERM by default.

-signal_number
A non-negative decimal integer that specifies the signal to send to TERM by default.

The following PIDs are of particular importance:
-1 If superuser, then broadcast the signal to all processes; otherwise broadcast to all processesbelong-
ing for the user.

Some of the most commonly used signals are:

1 HUP (hang up) - hang up.
2 INT (interrupt) - interrupt.
3 QUIT (quit) - exit.
6 ABRT (abort) - interrupts.
9 KILL (non-catchable, non-ignorable kill)
14 ALRM ( alarm clock) - alarm.
15 TERM (software termination signal) - Software to stop the signal.

PKill

The "pkill" command allows you to use extended regular expression patterns and other matching criteria. Instead of using the PID, you can now kill the application by entering the process name. For example, to kill the Firefox browser, simply run the command:

#pkillFirefox

Because it matches the pattern regular expression, you can also enter part of the process name, for example:

#pkillfire

To avoid "killing" the wrong processes, you can do "pgrep -l [processname]" to the list of suitable processes.

The pkill command has many more options, for example, if you specify the "-u" option, it will allow you to specify a username or ID. In this example, we send the TERM signal to all processes owned by the 'nobody' user:

# pkill -u nobody

Killall

Killall uses the process name instead of the PID, and it "kills" all process instances with the same name. For example, if you are using multiple instances Firefox browser, you can kill them all with the command:

# killall firefox

In Gnome, you can restart Nautilus with the command:

# killall nautilus

xkill

Xkill is a graphical way to "kill" an application. When you type "XKill" in the terminal, the mouse cursor will immediately become a "cross". All you have to do is click "cross" on the offending app and it will kill the app instantly. If you're interested, you can add a keyboard shortcut to enable the XKill feature.

Other signals that are used

SIGABRT

This signal sends a signal to the process to abort the operation. ABRT is usually directed at the process itself when it calls the abort() function of the C programming language to signal an abort, but it can be directed from any process like any other signal.

SIGALRM, SIGVTALRM and SIGPROF

An ALRM, VTALRM, and/or PROF signal is sent to a process when the time limit specified when calling an alarm function (eg, setitimer) expires.

ALRM

Sent when the present time or the clock has passed.

VTALRM

Sent when the CPU time used by the process has expired.

PROF

Sent when the processor time used by the process and system on behalf of the process expires.

SIGBUS

A BUS signal is sent to a process when it results in a bus error. Conditions that result in this signal, such as incorrect memory access alignment or missing physical address.

SIGCHLD

The CHLD signal is sent to a process when a child process terminates, is interrupted, or resumes after being interrupted. One common use of a signal is to signal the OS to clean up resources that are being used by a child process after it has finished without an explicit system call.

SIGCONT

The CONT signal instructs the operating system to restart a process that was previously suspended by a STOP or TSTP signal. One of important features this signal is to control the operation of the Unix shell.

SIGFPE

The FPE signal is sent to a process when it performs an erroneous arithmetic operation, such as division by zero.

SIGHUP

The HUP signal is sent to a process when its controlling terminal is closed. It was originally designed to notify a process after a successive line drop (HUP responsible for "hangups"). AT modern systems, this signal usually means that the pseudo or virtual terminal control has been closed.

SIGILL

ILL signal sent to a process when it tries to execute malicious, unknown, or privileged commands (instructions).

SIGINT

The INT signal is sent to a process from the controlling terminal when the user wishes to terminate the process. This is usually initiated by pressing Control-C, but on some systems, "delete" or "break".

SIGKILL

The KILL signal is sent to a process to terminate immediately. Unlike SIGTERM and SIGINT, this signal cannot be captured or ignored, and the receiving process cannot perform any cleanup after receiving this signal.

SIGPIPE

The PIPE signal is sent to a process when it tries to write to a pipe without a process connected to the other end.

SIGQUIT

The QUIT signal is sent to a process from its controlling terminal when the user requests the process to dump.

SIGSEGV

The SEGV signal is sent to a process when it makes an invalid reference virtual memory or segmentation failure, i.e. when it performs a segmentation violation.

SIGSTOP

The STOP signal tells the OS to stop the process for later resumption.

SIGTERM

The TERM signal is sent to a process to request that it terminate. Unlike the kill signal, it can be interpreted or ignored by the process. This allows the process to perform "nice" execution to stop releasing resources and save state if needed. It should be noted that SIGINT is almost identical to SIGTERM.

SIGTSTP

A TSTP signal is sent to its controlling terminal process and tells it to suspend temporarily. This is usually initiated by the user by pressing Control-Z. Unlike SIGSTOP, this process can register a signal handler or to ignore a signal.

SIGTTIN and SIGTTOU

In TTIN and TTOU, signals are sent to a process when it tries to read or write, respectively, from a (tty) terminal in the background. As a rule, this signal can only be received by processes under control. working panel; daemons do not have control terminals and should never receive this signal.

SIGUSR1 and SIGUSR2

The USR1 and USR2 signals are sent to a process and indicate user-defined conditions.

SIGPOLL

The POLL signal is sent to a process when an asynchronous I/O event occurs.

SIGSYS

The SYS signal is sent to a process when it passes a bad argument to a system call.

SIGTRAP

A TRAP signal is sent to a process when a condition occurs that the debugger asked to be informed - For example, when a particular function is executed or when a certain value variable.

SIGURG

A URG signal is sent to a process when the socket has urgent or out of range data available for reading.

SIGXCPU

The XCPU signal is sent to a process when it uses the CPU for more than a certain amount of time. set value set by the user. The arrival of the XCPU signal ensures that the process quickly saves all intermediate results and terminates gracefully before it is terminated by the operating system with a SIGKILL signal.

SIGXFSZ

The XFSZ signal is sent to a process when a file grows larger (greater than the specified value) than the maximum allowed value.

SIGRTMIN to SIGRTMAX

The RTMIN - RTMAX signals are for custom use. They are real time signals.

Miscellaneous Signals

The following signals are not standardized by POSIX, but are sometimes used on some systems.

SIGEMT

The EMT signal is sent in the process when an emulator interrupt occurs.

SIGINFO

The INFO signal is sent in the process when a status request is received from the controlling terminal.

SIGPWR

The PWR signal is sent in the process when the system experiences a power failure.

SIGLOST

The LOST signal is sent to a process when a "file lock" is lost.

SIGWINCH

The WINCH signal is sent to a process when its controlling terminal changes its size.

Sending signals from the keyboard

Signals can be sent from the keyboard. A few standard defaults are listed below. The default keyboard shortcuts for sending interrupt signals can be defined using the stty command.

CTRL-C

Send SIGINT (interrupt). By default, this causes the process to terminate.

CTRL-Z

Send SIGTSTP (Suspend). By default, this causes the process to suspend all operations.

CTRL-\

Send SIGQUIT (Quit). By default, this causes the process to terminate immediately and reset the kernel.

CTRL-T

Send SIGINFO (INFO). By default, this causes the operating system to display information about the command. Not supported on all systems.

conclusion

When applications misbehave and cause the system to freeze, it's very tempting to restart your computer and start your session all over again. With these "kill" commands, you can better manage the misbehavior of applications that cause or may cause a system crash. With this, I conclude this topic"The kill command in Unix/Linux".

Despite their stability, some applications in Linux sometimes hang. Sometimes apps stop responding or just run so slowly that you can't close them properly. One way to kill running application on Linux, this is the use of commands such as kill or killall. Let's see how to use these commands, find the PID of a process, and send a SIGKILL signal.

By process, we mean a copy of a program running on the system. For example, if you have three calculator windows open (for example, gcalctool), this means that you have started three processes.

Finding the PID of a hung process

Every process in Linux has its own process ID called PID. Before you can stop a process, you need to determine its PID. To do this, we use the ps and grep commands. ps command is designed to display a list of active processes in the system and information about them. grep command runs at the same time as ps (in a pipe) and will search through the results of the ps command. You can list all processes by running command line:

But, as a rule, the list is very large and finding the process that we want to "kill" is not so easy. This is where the grep command comes in. For example, to find information about a process named gcalctool, run the command:

Ps axu | grep gcalctool

The grep command will search through the results of the ps command and only those lines that contain the string (word) gcalctool will be displayed. There is one interesting detail here, for example, if you do not have the gcalctool application running, then after executing ps axu | grep gcalctool You'll get:

$ ps axu | grep gcalctool yuriy 25587 0.0 0.0 10636 884 pts/2 S+ 10:20 0:00 grep --color=auto gcalctool

That is, we got the grep process itself, since we specified the word gcalctool as a command parameter, and grep found itself in the command output ps.

If the gcalctool process is running, then we get:

[email protected]:~$ ps axu | grep gcalctool yuriy 25609 7.6 0.4 500840 17964 ? Sl 10:20 0:00 gcalctool yuriy 25624 0.0 0.0 10640 884 pts/2 S+ 10:21 0:00 grep --color=auto gcalctool

Here we are interested in the line: yuriy 25609 7.6 0.4 500840 17964 ? Sl 10:20 0:00 gcalctool". The number 25609 is the ID (PID) of the gcalctool process.

There is another easier way to find out the PID of a process - this is pidof command, which takes the name of the process as a parameter and outputs its PID. An example of executing the pidof command:

$ pidof gcalctool 25609

"Kill" the process with the kill command

Once the PID of a process is known, we can kill it. kill command. The kill command takes the PID of the process as a parameter. For example, let's kill the process with the number 25609:

Kill 25609

In general, the kill command is intended to send a signal to a process. By default, if we do not specify which signal to send, the SIGTERM signal is sent (from the word termination - termination). SIGTERM tells the process to terminate. Each signal has its own number. SIGTERM is number 15. A list of all the signals (and their numbers) that the kill command can send can be displayed by typing kill -l. To send a SIGKILL signal (numbered 9) to process 25609, run:

Kill-9 25609

The SIGTERM signal may not stop the process (for example, when intercepting or blocking the signal), SIGKILL always kills the process, since it cannot be caught or ignored.

Kill processes with the killall command

killall command in Linux is designed to "kill" all processes that have the same name. This is convenient since we don't need to know the PID of the process. For example, we want to close all processes named gcalctool. Run in terminal:

Killall gcalctool

The killall command, like kill, sends a SIGTERM signal by default. To send another signal, use the option -s. For example:

Killall -s 9 gcalctool

Conclusion

Some processes cannot be stopped under regular user. For example, if the process was started as root user or on behalf of another user on the system, then the kill and killall commands must be executed on behalf of the superuser, adding sudo (on Ubuntu):

Sudo kill 123

There are times when you work in GUI(e.g. GNOME) and you can't open a terminal emulator to stop a hung process. Then you can switch to the virtual console with the keys Ctrl+Alt+F1, log in to it and execute commands already from it. And then go back by clicking Ctrl+Alt+F7.

Help on using any command can be obtained with the man command:

Man ps man grep man pidof man kill man killall

Tasks and processes

Any performed in Linux program called process. Linux as a multitasking system is characterized by the fact that many processes belonging to one or more users can be running simultaneously. You can display a list of currently executing processes with the command ps, for example, as follows:

/home/larry# ps PID TT STAT TIME COMMAND 24 3 S 0:03 (bash) 161 3 R 0:00 ps /home/larry#

Note that the default command ps displays a list of only those processes that are owned by the user who launched it. To view all processes running in the system, you need to issue the command ps-a . Process numbers(process ID, or PID ) listed in the first column are unique numbers that the system assigns to each running process. The last column, titled COMMAND, indicates the name of the command that is running. In this case, the list contains processes that were started by the user larry himself. There are many other processes running in the system, full list can be viewed with the command ps-aux. However, among the commands run by the user larry , there is only bash (the shell for the user larry) and the command itself ps. It can be seen that the bash shell is running at the same time as the command ps. When the user entered the command ps, the bash shell started executing it. After the command ps has finished its work (the process table is displayed), control returns to the bash process. The bash shell then displays a prompt and waits for a new command.

A running process is also called task(job). The terms process and task are interchangeable. However, it is common to refer to a process as a task when they mean job control(job control). Job control is a command shell feature that provides the user with the ability to switch between multiple jobs.

In most cases, users will only run one task, which will be the last command they typed in the shell. However, many shells (including bash and tcsh ) have functions job management(job control), allowing you to run several commands at the same time or assignments(jobs) and, as needed, switch between them.

Job management can be useful if, for example, you are editing a large text file and want to temporarily stop editing to do something else. Using the job control functions, you can temporarily leave the editor, return to the shell prompt, and do something else. When they are done, you can return to work with the editor and find it in the same state in which it was left. There are many more useful uses for job control functions.

Foreground and background

Tasks can be either foreground(foreground), or background(background). There can only be one job in the foreground at any given time. The task in the foreground is the task you are interacting with; it receives input from the keyboard and sends the output to the screen (unless, of course, you have redirected the input or output somewhere else). Against, background jobs do not receive input from the terminal; as a rule, such tasks do not need interaction with the user.

Some tasks take a very long time to complete, and nothing interesting happens during their execution. An example of such tasks is compiling programs, as well as compressing large files. There is no reason to look at the screen and wait for these tasks to complete. These jobs should run in the background. During this time, you can work with other programs.

To control the execution of processes in Linux, a transfer mechanism is provided. signals. A signal is the ability of processes to exchange standard short messages directly with the system. The signal message does not contain any information, except for the signal number (for convenience, instead of the number, you can use a system-predefined name). In order to send a signal, it is enough for the process to use the system call kill(), and in order to receive a signal, nothing is needed. If a process needs to react in a special way to a signal, it can register handler, and if there is no handler, the system will respond for it. Typically, this causes the process that received the signal to terminate immediately. Signal handler starts asynchronously, immediately after receiving the signal, no matter what the process is doing at that time.

Two signals - number 9 ( KILL) and 19 ( STOP) - always processed by the system. The first one is needed in order to kill the process for sure (hence the name). Signal STOP suspends process: in this state, the process is not removed from the process table, but it is not executed until it receives a signal 18 ( CONT) - after which it will continue to work. In a Linux shell, the signal STOP can be passed to an active process using an escape sequence ctrl -Z .

Signal number 15 ( TERM) is used to interrupt the job. At interruption(interrupt) job process dies. Interruption of jobs is usually done by the control sequence ctrl -C. There is no way to restore an interrupted task. You should also be aware that some programs intercept the signal TERM(using a handler), so that pressing the key combination ctrl -C(o) may not terminate the process immediately. This is done so that the program can destroy traces of its work before it is completed. In practice, some programs cannot be interrupted in this way at all.

Transferring to the background and destroying jobs

Let's start with a simple example. Consider the yes command, which at first glance may seem useless. This command sends an endless stream of lines consisting of the character y to standard output. Let's see how this command works:

/home/larry# yes y y y y y

The sequence of such lines will continue indefinitely. You can kill this process by sending it an interrupt signal, i.e. by pressing ctrl -C. Let's do it differently now. To prevent this endless sequence from being displayed on the screen, redirect the standard output of the yes command to /dev/null . As you may know, the /dev/null device acts like a "black hole": all data sent to this device is lost. With this device it is very convenient to get rid of too abundant output of some programs.

/home/larry# yes > /dev/null

Now nothing is displayed on the screen. However, the shell prompt is also not returned. This is because the yes command is still running and sending its messages consisting of the letters y to /dev/null . You can also kill this job by sending it an abort signal.

Let's say now that you want the yes command to continue to work, but the shell prompt should also return to the screen so that you can work with other programs. To do this, you can put the yes command in the background, and it will work there without communicating with you.

One way to put a process into the background is to add an & to the end of the command. Example:

/home/larry# yes > /dev/null & + 164 /home/larry#

The message is job number(job number) for the yes process. The shell assigns a job number to each executable job. Because yes is the only job executable, it is assigned the number 1. The number 164 is the process ID number (PID ) associated with this process, and this number is also given to the process by the system. As we will see later, a process can be referred to using both of these numbers.

So now we have the yes command process running in the background, continuously sending a stream of y's to /dev/null . In order to find out the status of this process, you need to execute the command jobs, which is an internal shell command.

/home/larry# jobs + Running yes >/dev/null & /home/larry#

We see that this program really works. To check the status of a task, you can also use the command ps, as shown above.

In order to send a signal to the process (most often there is a need interrupt job operation) the utility is used kill. This command is given either a job number or a PID as an argument. An optional parameter is the number of the signal to be sent to the process. Signal sent by default TERM. In the case above, the job number was 1, so the command kill %1 will abort the job. When a job is referred to by its number (rather than PID ), then that number must be prefixed on the command line with a percent sign ("%").

Now let's enter the command jobs again to check the result of the previous action:

/home/larry# jobs Terminated yes >/dev/null

In fact, the job is destroyed, and the next time you enter the jobs command, there will be no information about it on the screen.

You can also kill a job using the process identification number (PID). This number, along with the job ID, is given when the job is started. In our example, the PID value was 164, so the command kill 164 would be equivalent to the command kill %1. When using the PID as an argument to the kill command, you do not need to enter the "%" character.

Pausing and resuming jobs

Let's start the process first with the yes command in the foreground, as we did before:

/home/larry# yes > /dev/null

As before, since the process is running in the foreground, the shell prompt is not returned to the screen.

Now instead of interrupting the task with a key combination ctrl -C, the task can suspend(suspend, literally - hang up), sending him a signal STOP. To pause the task, you must press the appropriate key combination, usually this ctrl -Z .

/home/larry# yes > /dev/null ctrl -Z+ Stopped yes >/dev/null /home/larry#

A suspended process simply does not run. It does not consume CPU resources. A suspended task can be started from the same point as if it had not been suspended.

To resume a job in the foreground, you can use the command fg(from the word foreground - foreground).

/home/larry# fg yes >/dev/null

The shell will display the name of the command again, so the user will know which task they are in. this moment launched in the foreground. Pause this task again by pressing the keys ctrl -Z, but this time we will run it in the background with the command bg(from the word background - background). This will cause the given process to work as if the command with the & character at the end was used when starting it (as was done in the previous section):

/home/larry# bg + yes $>$/dev/null & /home/larry#

This returns the shell prompt. Team now jobs should show that the process yes really works at the moment; this process can be killed with the command kill, as it was done before.

You can't use the keyboard shortcut to pause a job that's running in the background. ctrl -Z. Before suspending a task, it must be brought to the foreground with the command fg and only then stop. Thus the command fg can be applied to either suspended jobs or a job running in the background.

There is a big difference between jobs in the background and suspended jobs. The suspended task does not work - it does not spend computing power processor. This job does nothing. The suspended task occupies a certain amount of computer RAM, after a while the kernel will pump out this part of the memory to HDD « poste restante". On the contrary, a task in the background is running, using memory and doing some things that you may need, but you can work with other programs at the same time.

Jobs running in the background may be trying to display some text on the screen. This will interfere with work on other tasks.

/home/larry# yes &

Here, stdout has not been redirected to /dev/null , so an endless stream of y characters will be printed to the screen. This thread cannot be stopped because the key combination ctrl -C does not affect jobs in the background. In order to stop this issuance, you need to use the command fg, which will bring the task to the foreground, and then kill the task with a key combination ctrl -C .

Let's make one more remark. Usually a team fg and team bg affect the jobs that were last paused (these jobs will be marked with a + symbol next to the job number if you enter the command jobs). If one or more jobs are running at the same time, jobs can be placed in the foreground or in the background by giving command arguments fg or commands bg their identification number (job ID). For example, the command fg %2 puts job number 2 in the foreground, and the command bg %3 puts job number 3 in the background. Use PID as command arguments fg and bg it is forbidden.

Moreover, to bring a job to the foreground, you can simply specify its number. Yes, the team %2 will be equivalent to the command fg %2 .

It is important to remember that the job control function belongs to the shell. Teams fg , bg and jobs are internal shell commands. If, for some reason, you are using a command shell that does not support job control functions, then you will not find these (and similar) commands in it.

The -9 (or KILL) argument to the kill command should only be used on POSIX-compliant systems if absolutely necessary. Why? The KILL signal cannot be handled by the process. This means that after terminating a process with kill -9 , the child processes will remain in memory and become orphaned, file system will be littered with temporary files, shared memory segments will be active, sockets will be hung, and atexit(3) will not be executed at all. As a result, there is a risk of encountering unexpected and difficult to debug problems.

Use the default signal TERM instead, and use KILL only if less problematic signals prove to be ineffective:

$ kill 6738
$ kill -INT 6738
$ kill -HUP 6738
$ kill -KILL 6738

If even the KILL signal fails to kill the process, it means that the process is most likely stuck in an I/O operation or is in some other unterminated state. You may need to reboot or force unmount the buggy network drive.

The default use of kill -KILL is acceptable when dealing with a problematic application, for example older versions of Netscape would often only terminate with the KILL signal. However, this is a rare exception to the rule: use KILL on and only those known applications.

Problems that occur when terminating processes

Sequentially sending different signals can cause the following problems: firstly, the process may take seconds, or even tens of seconds, to gracefully terminate. One product I've used took over 30 seconds to complete correctly after receiving the TERM signal. Fortunately, this feature was discovered during testing, so a suitable script was written for this case. Secondly, sometimes there are situations when the old process terminated, while the new process took its ID in the interval between the TERM and KILL signals. Systems with high process turnover and systems where the kernel randomly assigns PIDs, such as OpenBSD, are particularly at risk. Checking the process name or its PPID doesn't always help, as the new process can be a fork of the same parent and have the same name, so particularly paranoid scripts might also check the process creation time or other metadata before sending the signal. Perhaps these situations are rare, but they are worth considering if you have to deal with a critical process.

Process termination signals

Process termination signals can be identified by name or sequence number: kill -1 and kill -HUP are equivalent. However, using the name of the signal is safer, since it's easy to misspell the -1 argument, sending the signal to another process or even a group of processes. Also, always try to use the name in scripts, as this will help you better understand what type of signal is being sent to whoever will be reading your code.

The HUP signal hangs the shell, so this good way clear a shell that is hanging waiting for input, or close the SSH session.

More detailed information about process termination signals is specified in

The -9 (or KILL) argument to the kill command should only be used on POSIX-compliant systems if absolutely necessary. Why? The KILL signal cannot be handled by the process. This means that after terminating a process with kill -9 , child processes will be left in memory and become orphaned, the filesystem will be littered with temporary files, shared memory segments will be active, sockets will be hung, and atexit(3 ) will not be executed at all. As a result, there is a risk of encountering unexpected and difficult to debug problems.

Use the default signal TERM instead, and use KILL only if less problematic signals prove to be ineffective:

$ kill 6738
$ kill -INT 6738
$ kill -HUP 6738
$ kill -KILL 6738