Terminating a Process from CMD: Softest to Hardest
I was wondering if anyone had experience using command line to terminate processes using taskkill and WIMC.
I was wondering if anyone knew the order of how "hard" of a close/terminate these commands are from the command that is the "softest" (least forceful) close to the command that is the "hardest" (most forceful):
My guess would be:
Least/Softest
1) taskkill /im processname.exe
2) wmic process where name="processname.exe" call terminate
3) wmic process where name='processname.exe' delete
4) taskkill /f /im processname.exe
Most/Hardest
I am trying to create a batch command file and wanted to just know the difference between these, to see which I should use.
I prefer to use a softer close, check to see if the process is still running, and then try a harder close, and then repeat this until the program is successfully closed. Any info on the difference between any of these would be helpful, especially between using terminate and delete via CMD: WMIC would be helpful, as I cannot find documentation anywhere on them.
As CatCat mentioned, there are two main ways to terminate a process : WM_CLOSE and TerminateProcess(). I've included two more for completeness sake.
Sending window message WM_CLOSE to the main window of the process. This is the same message an application receives when user clicks X button to close the window. The app may then gracefully shutdown or ask user for confirmation - for example if some work is unsaved.
taskkill without /f appears to attempt doing that but seems to not always succeed in finding the correct window to close. If the app is supposed to not have a visible window (such as if it only displays an icon in system tray or is a windowless server) it may ignore this message entirely.
If taskkill does not work for you, it is possible NirCmd: does better job: NirCmd.exe closeprocess iexplore.exe
There is also WM_ENDSESSION message - it it sent by the OS when shutting down (after WM_QUERYENDSESSION). It works pretty much the same way except it is sent to whole application rather then a specific window. Depending on parameters, apps may be requested to save the work into temporary files because the system needs to restart to apply some updates. Some applications react to this message, some don't.
It should be possible to send these messages manually, but I have not seen it done other than to test how app reacts to shutdown without actually shutting down OS.
WM_QUIT message suggests the application as a whole needs to shut down (more specifically, it is sent to a thread). An application should normally post it to itself after its window is done closing and now it is time to end the process.
It is possible to manually post the message to every thread of another process but this is hackish and rare, it may crash processes not expecting to be issued this message from outside. I'm not sure if it's a better option than just terminating the process or not.
TerminateProcess() tells the OS to forcefully terminate the process. This is what happens when you click End process button on processes tab in the task manager. The process does not get notified it is being closed - it is just stopped where it was and removed from the memory - no questions, no shutdown, etc.
This may cause corruption if some files were being written at that time or data transferred.
That is what taskkill /f command does. Both wmic process call terminate and wmic process delete appear to also do this although I'm not sure.
using wmic:
print all running process where name of process is cmd.exe
wmic process where name="cmd.exe" GET ProcessId, CommandLine,CreationClassName
then terminate the specific instance of process by processId (PID)
WMIC PROCESS WHERE "ProcessID=13800" CALL TERMINATE
Related
I am a system administrator and I have been asked to run a linux script to clean the system.
The command is this:
perl script.pl > output.log &
so this command is ending with a & sign, is there any special significance of it?
I have basic knowledge of shell but I have never seen this before.
The & makes the command run in the background.
From man bash:
If a command is terminated by the control operator &, the shell
executes the command in the background in a subshell. The shell does
not wait for the command to finish, and
the return status is 0.
When not told otherwise commands take over the foreground. You only have one "foreground" process running in a single shell session. The & symbol instructs commands to run in a background process and immediately returns to the command line for additional commands.
sh my_script.sh &
A background process will not stay alive after the shell session is closed. SIGHUP terminates all running processes. By default anyway. If your command is long-running or runs indefinitely (ie: microservice) you need to pr-pend it with nohup so it remains running after you disconnect from the session:
nohup sh my_script.sh &
EDIT: There does appear to be a gray area regarding the closing of background processes when & is used. Just be aware that the shell may close your process depending on your OS and local configurations (particularly on CENTOS/RHEL):
https://serverfault.com/a/117157.
In addition, you can use the "&" sign to run many processes through one (1) ssh connections in order to to keep minimum number of terminals. For example, I have one process that listens for messages in order to extract files, the second process listens for messages in order to upload files: Using the "&" I can run both services in one terminal, through single ssh connection to my server.
These processes running through the "&" will also "stay alive" after ssh session is closed. Pretty neat and useful if the ssh connection to the server is interrupted and no terminal multiplexer (screen, tmux, byobu) was used.
I don’t know for sure but I’m reading a book right now and what I am getting is that a program need to handle its signal ( as when I press CTRL-C). Now a program can use SIG_IGN to ignore all signals or SIG_DFL to restore the default action.
Now if you do $ command & then this process running as background process simply ignores all signals that will occur. For foreground processes these signals are not ignored.
If you have a command which executes and doesn't return status 0(control of prompt) quickly.
For example:
command gedit launches the default editor gedit UI.
commandeclipse launches eclipse IDE.
Such commands keep throwing the logs of activities in the terminal and don't return the command prompt.
Question is, how to run such commands in background so that, we will get back command terminal and we can use terminal for other tasks.
Answer is: by appending & after such command.
user#mymachine:~$ <command> &
Examples:
user#mymachine:~$ edit &
user#mymachine:~$ eclipse &
as Ctrl+C copies the current selection rather than killing the current application in ConEmu, I wonder how to do the latter now. I know that there is Ctrl+Alt+Break (Terminate (kill) active process in the current console: Close(1)), but does this behave the same as pressing Ctrl+C in a plain old cmd.exe window?
AFAIK Ctrl+C usually sends SIGINT (or whatever windows has instead) prior to killing the window so that the application can exit voluntarily.
Thanks!
The solution is to assign the hotkey Ctrl+C to an arbitrary macro (01-32) that is configured to run "Break(1)":
The existing binding of Ctrl+C to the "Copy" command must be removed.
Is pressing ctrl + c while running batch job and taskkill /f /im cmd.exe same?
Actually I want to close three batch jobs ((2)cmd's and (1)bat files) through batch script. I found there is no command for stop like start. I don't want to kill parent image name (cmd.exe) as well using force taskkill. Manually I used to press ctrl + c to terminate the job. I don't want to use this any more. Is there any way to kill/stop the running job rather that force taskkill?
Thanks for your time!
This has to be set from one of the console programs. You'll need to write a program to do it.
GenerateConsoleCtrlEvent
Sends a specified signal to a console process group that shares the console associated with the calling process.
BOOL WINAPI GenerateConsoleCtrlEvent(
DWORD dwCtrlEvent,
DWORD dwProcessGroupId
);
Parameters
dwCtrlEvent
[in] Type of signal to generate. This parameter can be one of the following values.
Value Meaning
CTRL_C_EVENT
0 Generates a CTRL+C signal. This signal cannot be generated for process groups. If dwProcessGroupId is nonzero, this function will succeed, but the CTRL+C signal will not be received by processes within the specified process group.
CTRL_BREAK_EVENT
1 Generates a CTRL+BREAK signal.
If you run a .bat or .cmd file with %0|%0 inside, your computer starts to use a lot of memory and after several minutes, is restarted. Why does this code block your Windows? And what does this code programmatically do? Could it be considered a "bug"?
This is the Windows version of a fork bomb.
%0 is the name of the currently executing batch file. A batch file that contains just this line:
%0|%0
Is going to recursively execute itself forever, quickly creating many processes and slowing the system down.
This is not a bug in windows, it is just a very stupid thing to do in a batch file.
This is known as a fork bomb.
It keeps splitting itself until there is no option but to restart the system.
http://en.wikipedia.org/wiki/Fork_bomb
What it is:
%0|%0 is a fork bomb. It will spawn another process using a pipe | which runs a copy of the same program asynchronously. This hogs the CPU and memory, slowing down the system to a near-halt (or even crash the system).
How this works:
%0 refers to the command used to run the current program. For example, script.bat
A pipe | symbol will make the output or result of the first command sequence as the input for the second command sequence. In the case of a fork bomb, there is no output, so it will simply run the second command sequence without any input.
Expanding the example, %0|%0 could mean script.bat|script.bat. This runs itself again, but also creating another process to run the same program again (with no input).
%0 will never end, but it never creates more than one process because it instantly transfers control to the 2nd batch script (which happens to be itself).
But a Windows pipe creates a new process for each side of the pipe, in addition to the parent process. The parent process can't finish until each side of the pipe terminates. So the main program with a simple pipe will have 3 processes. You can see how the bomb quickly get's out of control if each side of the pipe recursively calls the parent batch!
It's a logic bomb, it keeps recreating itself and takes up all your CPU resources. It overloads your computer with too many processes and it forces it to shut down. If you make a batch file with this in it and start it you can end it using taskmgr. You have to do this pretty quickly or your computer will be too slow to do anything.
I am working on an application where I need to detect a system shutdown.
However, I have not found any reliable way get a notification on this event.
I know that on shutdown, my app will receive a SIGTERM signal followed by a SIGKILL. I want to know if there is any way to query if a SIGTERM is part of a shutdown sequence?
Does any one know if there is a way to query that programmatically (C API)?
As far as I know, the system does not provide any other method to query for an impending shutdown. If it does, that would solve my problem as well. I have been trying out runlevels as well, but change in runlevels seem to be instantaneous and without any prior warnings.
Maybe a little bit late. Yes, you can determine if a SIGTERM is in a shutting down process by invoking the runlevel command. Example:
#!/bin/bash
trap "runlevel >$HOME/run-level; exit 1" term
read line
echo "Input: $line"
save it as, say, term.sh and run it. By executing killall term.sh, you should able to see and investigate the run-level file in your home directory. By executing any of the following:
sudo reboot
sudo halt -p
sudo shutdown -P
and compare the difference in the file. Then you should have the idea on how to do it.
There is no way to determine if a SIGTERM is a part of a shutdown sequence. To detect a shutdown sequence you can either use use rc.d scripts like ereOn and Eric Sepanson suggested or use mechanisms like DBus.
However, from a design point of view it makes no sense to ignore SIGTERM even if it is not part of a shutdown. SIGTERM's primary purpose is to politely ask apps to exit cleanly and it is not likely that someone with enough privileges will issue a SIGTERM if he/she does not want the app to exit.
From man shutdown:
If the time argument is used, 5 minutes before the system goes down
the /etc/nologin file is created to ensure that further logins shall
not be allowed.
So you can test existence of /etc/nologin. It is not optimal, but probably best you can get.
Its a little bit of a hack but if the server is running systemd if you can run
/bin/systemctl list-jobs shutdown.target
... it will report ...
JOB UNIT TYPE STATE
755 shutdown.target start waiting <---- existence means shutting down
1 jobs listed.
... if the server is shutting down or rebooting ( hint: there's a reboot.target if you want to look specifically for that )
You will get No jobs running. if its not being shutdown.
You have to parse the output which is a bit messy as the systemctl doesnt return a different exit code for the two results. But it does seem reasonably reliable. You will need to watch out for a format change in the messages if you update the system however.
Making your application responding differently to some SIGTERM signals than others seems opaque and potentially confusing. It's arguable that you should always respond the same way to a given signal. Adding unusual conditions makes it harder to understand and test application behavior.
Adding an rc script that handles shutdown (by sending a special signal) is a completely standard way to handle such a problem; if this script is installed as part of a standard package (make install or rpm/deb packaging) there should be no worries about control of user machines.
I think I got it.
Source =
https://github.com/mozilla-b2g/busybox/blob/master/miscutils/runlevel.c
I copy part of the code here, just in case the reference disappears.
#include "libbb.h"
...
struct utmp *ut;
char prev;
if (argv[1]) utmpname(argv[1]);
setutent();
while ((ut = getutent()) != NULL) {
if (ut->ut_type == RUN_LVL) {
prev = ut->ut_pid / 256;
if (prev == 0) prev = 'N';
printf("Runlevel: prev=%c current=%c\n", prev, ut->ut_pid % 256);
endutent();
return 0;
}
}
puts("unknown");
see man systemctl, you can determine if the system is shutting down like this:
if [ "`systemctl is-system-running`" = "stopping" ]; then
# Do what you need
fi
this is in bash, but you can do it with 'system' in C
The practical answer to do what you originally wanted is that you check for the shutdown process (e.g ps aux | grep "shutdown -h" ) and then, if you want to be sure you check it's command line arguments and time it was started (e.g. "shutdown -h +240" started at 14:51 will shutdown at 18:51).
In the general case there is from the point of view of the entire system there is no way to do this. There are many different ways a "shutdown" can happen. For example someone can decide to pull the plug in order to hard stop a program that they now has bad/dangerous behaviour at shutdown time or a UPS could first send a SIGHUP and then simply fail. Since such a shutdown can happen suddenly and with no warning anywhere in a system there is no way to be sure that it's okay to keep running after a SIGHUP.
If a process receives SIGHUP you should basically assume that something nastier will follow soon. If you want to do something special and partially ignore SIGHUP then a) you need to coordinate that with whatever program will do the shutdown and b) you need to be ready that if some other system does the shutdown and kills you dead soon after a SIGHUP your software and data will survive. Write out any data you have and only continue writing to append-only files with safe atomic updates.
For your case I'm almost sure your current solution (treat all SIGHUPs as a shutdown) is the correct way to go. If you want to improve things, you should probably add a feature to the shutdown program which does a notify via DBUS or something similar.
When the system shuts down, the rc.d scripts are called.
Maybe you can add a script there that sends some special signal to your program.
However, I doubt you can stop the system shutdown that way.