Kill all script

-
  Download Here --> https://tinyurl.com/2s39bs69    (Copy and Paste Link)






 Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
 CBROX-Kill-All / Kill All.lua
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

  Open with Desktop
  View raw
  Copy raw contents Copy raw contents Copy raw contents
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
   local UserInputService = game: GetService ( " UserInputService " )   local Players = game: GetService ( " Players " )   local Typing = false   local KillAllKey = Enum. KeyCode . E  UserInputService. TextBoxFocused : Connect ( function ()   Typing = true   end )  UserInputService. TextBoxFocusReleased : Connect ( function ()   Typing = false   end )  UserInputService. InputBegan : Connect ( function ( Input )   if Input. KeyCode == KillAllKey and Typing == false then   for _, v in next, Players: GetPlayers () do   if v. Name ~= Players. LocalPlayer . Name then   if v. TeamColor ~= Players. LocalPlayer . TeamColor then   if v. Character ~= nil and v. Character . Humanoid . Health ~= 0 then   local Arguments =   PartHit = workspace[v. Name ]. HeadHB , -- Part that the bullet hit.   HitPos = workspace[v. Name ]. HeadHB . Position , -- 3D Position of where the bullet hit.   WeaponName = " AWP " , -- Change to a weapon (must be valid) if you want. I use AWP because it deals the most damage.   Number = 4096 ,   GunInstance = nil ,   Nothing = nil ,   Nothing2 = nil ,   Number2 = 1 ,   Boolean = false ,   Headshot = true , -- Whether or not the shot was a headshot.   VectorPosition = Vector3. new ( 0 , 0 , 0 ), -- Where the bullet comes from.   Number3 = 41022 ,   Normal = Vector3. new ( 0 , 0 , 0 ) -- The bullet mark's orientation (Third argument of a raycast).   >   for i = 1 , 5 do   game: GetService ( " ReplicatedStorage " ). Events . HitPart : FireServer ( unpack (Arguments))   end   end   end   end   end   end   end )
Kill all descendant processes [duplicate]
I'm writing an application. It has the ability to spawn various external processes. When the application closes, I want any processes it has spawned to be killed. Sounds easy enough, right? Look up my PID, and recursively walk the process tree, killing everything in sight, bottom-up style. Except that this doesn't work. In one specific case, I spawn foo , but foo just spawns bar and then immediately exits, leaving bar running. There is now no record of the fact that bar was once part of the application's process tree. And hence, the application has no way of knowing that it should kill bar . I'm pretty sure I can't be the first person on Earth to try to do this. So what's the standard solution? I guess really I'm looking for some way to "tag" a process in such a way that any process it spawns will unconditionally inherit the same tag. (So far, the best I can come up with is running the application as a different user. That way, you can just indescriminently kill all processes beloning to that user. But this has all sorts of access permission problems. )
@Gilles I disagree that PGID is the best way to do this. For me simply doing sh -c 'sleep 10m' & ps -jH shows that the sh command has a different PGID from the calling shell.
5 Answers 5
Update
This is one of those ones where I clearly should have read the question more carefully (though seemingly this is the case with most answers on to this question). I have left the original answer intact because it gives some good information, even though it clearly misses the point of the question.
Using SID
I think the most general, robust approach here (at least for Linux) is to use SID (Session ID) rather than PPID or PGID. This is much less likely to be changed by child processes and, in the case of shell script, the setsid command can be used to start a new session. Outside of the shell the setuid system call can be used.
For a shell that is a session leader, you can kill all the other processes in the session by doing (the shell won't kill itself):
Note: The trailing equals sign in argument pid= removes the PID column header.
Otherwise, using system calls, call getsid for each process seems like the only way.
Using a PID namspace
This is the most robust approach, however the downsides are that it is Linux only and that it needs root privileges. Also the shell tools (if used) are very new and not widely available.
For a more detailed discussion of PID namespaces, please see this question - Reliable way to jail child processes using `nsenter:`. The basic approach here is that you can create a new PID namespace by using the CLONE_NEWPID flag with the clone system call (or via the unshare command).
When a process in a PID namespace is orphaned (ie when it parent process finishes), it is re-parented to the top level PID namespace process rather than the init . This means that you can always identify all the descendants of the top level process by walking the process tree. In the case of a shell script the PPID approach below would then reliably kill all descendants.
Further reading on PID namespaces:
Original Answer
Killing child processes
The easy way to do this in a shell script, provided pkill is available is:
This kills all children of the current given process ( $$ expands to the PID of the current shell).
If pkill isn't available, a POSIX compatible way is:
Killing all descendent processes
Another situation is that you may want to kill all the descendants of the current shell process as well as just the direct children. In this case you can use the recursive shell function below to list all the descendant PIDs, before passing them as arguments to kill:
list_descendants () kill $(list_descendants $$)
Double forks
One thing to beware of, which might prevent the above from working as expected is the double fork() technique. This is commonly used when daemonising a process. As the name suggests the process that is to be started runs in the second fork of the original process. Once the process is started, the first fork then exits meaning that the process becomes orphaned.
In this case it will become a child of the init process instead of the original process that it was started from. There is no robust way to identify which process was the original parent, so if this is the case, you can't expect to be able to kill it without having some other means of identification (a PID file for example). However, if this technique has been used, you shouldn't try to kill the process without good reason.
The descendant process needn't double fork - it can fork once, but if it does so it will be orphaned if its parent process later forks. This occurs all of the time, and is not necessarily related to intentional daemonization at all.
But we've all already answered how to kill all child processes in various ways - the question is not how to ensure one process becomes and remains the child of another. Can you get in testing ? Besides, I already did it: unix.stackexchange.com/questions/124162/…
What is supposed to happen when you kill the process running as pid 1 via unshare -p ? I had hoped that this would reliably kill all processes below it, so that you can "clean up" by killing a single process/cgroup root. But it seems that this results in all child processes to be reparented to the outer init .
where XXX is group number of process group you want to kill. You can check it using:
 $ ps x -o "%p %r %c" PID PGID COMMAND 2416 1272 gnome-keyring-d 2427 2427 gnome-session 2459 2427 lightdm-session 2467 2467 ssh-agent 2470 2427 dbus-launch 2471 2471 dbus-daemon 2484 2427 gnome-settings- 2489 2471 gvfsd 2491 2471 gvfs-fuse-daemo 2499 2427 compiz 2502 2471 gconfd-2 2508 2427 syndaemon 2513 2512 pulseaudio 2517 2512 gconf-helper 2519 2471 gvfsd-metadata
For more details about process groups ID, you can see man setpgid :
DESCRIPTION All of these interfaces are available on Linux, and are used for get‐ ting and setting the process group ID (PGID) of a process. The pre‐ ferred, POSIX.1-specified ways of doing this are: getpgrp(void), for retrieving the calling process's PGID; and setpgid(), for setting a process's PGID. setpgid() sets the PGID of the process specified by pid to pgid. If pid is zero, then the process ID of the calling process is used. If pgid is zero, then the PGID of the process specified by pid is made the same as its process ID. If setpgid() is used to move a process from one process group to another (as is done by some shells when creating pipelines), both process groups must be part of the same session (see setsid(2) and credentials(7)). In this case, the pgid specifies an existing process group to be joined and the session ID of that group must match the session ID of the joining process.
How to kill all subprocesses of shell?
I'm writing a bash script, which does several things. In the beginning it starts several monitor scripts, each of them runs some other tools. At the end of my main script, I would like to kill all things that were spawned from my shell. So, it might looks like this:
#!/bin/bash some_monitor1.sh & some_monitor2.sh & some_monitor3.sh & do_some_work . kill_subprocesses
The thing is that most of these monitors spawn their own subprocesses, so doing (for example): killall some_monitor1.sh will not always help. Any other way to handle this situation?
9 Answers 9
will fit (just kills its own descendants)
And here is the help of -P
 -P, --parent ppid. Only match processes whose parent process ID is listed.
@Chexpir: It's not part of bash. However, if you system does not have it, you are in deep5h1t. It's part of the procps package under Ubuntu, and this package contains other core utilities, like free , kill and ps .
Upvoting. Yet in my case the processes were pretty stubborn so I had to kill them with signal 9 as in pkill -P $$ --signal 9
@pihentagy Isn't there a race condition? pkill itself is a child of current shell. Therefor, will "pkill -P $$" kill the "pkill" process before all other processes being killed?
No, there is no race condition here. pkill is a symlink to pgrep and in pgrep.c on line 441 you can see that pkill will skip itself when checking for processes to kill. So after killing every other child, the pkill command will terminate regularly.
After starting each child process, you can get its id with
Then you can use the stored PIDs to find and kill all grandchild etc. processes as described here or here.
Just to add, if the monitors' subprocesses can spawn subsubprocesses etc., you'd need to use the technique described in the link recursively.
If you use a negative PID with kill it will kill a process group. Example:
Oops, I was wrong, this doesn't work. The negative argument needs to be a PGID not a PID . Sometimes those are the same leading to false positives.
Extending pihentagy's answer to recursively kill all descendants (not just children):
kill_descendant_processes()
kill_descendant_processes $$
will kill descedants of the current script/shell.
(Tested on Mac OS 10.9.5. Only depends on pgrep and kill)
Ok, but please don't use kill -9 "by default", give a change the processes to exit! serverfault.com/a/415744/55046
And if you have pgrep, you have pkill, then why not simply use my answer with pkill ? stackoverflow.com/a/17615178/26494
as mentoned before, pkill won't kill grandchildren. there is my minified version of this approach: k(); k PID
Caveat a race condition, using [code below] accomplishes what Jürgen suggested without causing an error when no jobs exist
Caveat a race condition, using 'test -z "`jobs -p`" || kill `jobs -p`' accomplishes what Jürgen suggested without causing an error when no jobs exist
jobs="$(jobs -p)"; [ -n "$jobs" ] && kill $jobs avoids the race condition of a process exiting between the two calls to jobs , is POSIX compliant, and is (IMO) less confusing than checking for an empty string and or'ing to kill
pkill with optioin "-P" should help:
pkill -P $(pgrep some_monitor1.sh)
 -P ppid. Only match processes whose parent process ID is listed.
There are some discussions on linuxquests.org, please check:
@pihentagy Each unique, running process (vs tool) on the system has a unique PID. If you open two terminals then a process monitor, the monitor will show two different "sh" processes, each with their own PID. However, you're right that you can clobber things, by getting processes by name, which need not be (and are often not) unique.
I like the following straightforward approach: start the subprocesses with an environment variable with some name/value and use this to kill the subprocesses later. Most convenient is to use the process-id of the running bash script i.e. $$. This also works when subprocesses starts another subprocesses as the environment is inherited.
So start the subprocesses like this:
MY_SCRIPT_TOKEN=$$ some_monitor1.sh & MY_SCRIPT_TOKEN=$$ some_monitor2.sh &
And afterwards kill them like this:
ps -Eef | grep "MY_SCRIPT_TOKEN=$$" | awk '' | xargs kill
Similar to above, just a minor tweak to kill all processes indicated by ps :
ps -o pid= | tail -n +2 | xargs kill -9
Perhaps sloppy / fragile, but seemed to work at first blush. Relies on fact that current process ( $$ ) tends to be first line.
Description of commands, in order:

  Print PIDs for processes in current terminal, excl. header column
  Start from Line 2 (excl. current terminal's shell)
  Kill those procs

I've incorporated a bunch of the suggestions from the answers here into a single function. It gives time for processes to exit, murders them if they take too long, and doesn't have to grep through output (eg, via ps )
#!/bin/bash # This function will kill all sub jobs. function KillJobs() >
I also tried to get a variation working with pkill, but on my system (xubuntu 21.10) it does absolutely nothing.
#!/bin/bash # This function doesn't seem to work. function KillChildren() >