Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I understand it's off topic, I couldn't find anywhere online and I was thinking maybe programming gurus in the community might know this.
I usually use
kill -9 pid
to kill the job. I always wondered the origin of 9. I looked it up online, and it says
"9 Means KILL signal that is not catchable or ignorable. In other words it would signal process (some running application) to quit immediately" (source: http://wiki.answers.com/Q/What_does_kill_-9_do_in_unix_in_its_entirety)
But, why 9? and what about the other numbers? is there any historical significance or because of the architecture of Unix?
See the wikipedia article on Unix signals for the list of other signals. SIGKILL just happened to get the number 9.
You can as well use the mnemonics, as the numbers:
kill -SIGKILL pid
There were 8 other signals they came up with first.
I think a better answer here is simply this:
mike#sleepycat:~☺ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX
As for the "significance" of 9... I would say there is probably none. According to The Linux Programming Interface(p 388):
Each signal is defined as a unique (small) integer, starting
sequentially from 1. These integers are defined in with
symbolic names of the form SIGxxxx . Since the actual numbers used for
each signal vary across implementations, it is these symbolic names
that are always used in programs.
First you need to know what are Signals in Unix-like systems (It'll take just few minutes).
Signals, are software interrupts sent to a (running) program to indicate that an important event has occurred.
The events can vary from user requests to illegal memory access
errors. Some signals, such as the interrupt signal, indicate that a
user has asked the program to do something that is not in the usual
flow of control.
There are several types of Signals we can use - to get a full list of all the available/possible Signals use "$ kill -l" command:
In the above output it's clearly visible, that each Signal has a 'signal number' (e.g. 1, 2, 3) and a 'signal name' (e.g. SIGUP, SIGINT, SIGQUIT) associated with it. For a detailed look up what each and every Signal does, visit this link.
Finally, coming to the question "Why number 9 in kill -9 command":
There are several methods of delivering signals to a program or script. One of commonly used method for sending signal is to use the kill command - the basic syntax is:
$ kill -signal pid
Where signal is either the number or name of the signal, followed by the process Id (pid) to which the signal will be sent.
For example - -SIGKILL (or -9), signal kills the process immediately.
$ kill -SIGKILL 1001
and
$ kill -9 1001
both command are one the same thing i.e. above we have used the 'signal name', and later we have used 'signal number'.
Verdict: One has an open choice to whether use the 'signal name' or 'signal number' with the kill command.
It's a reference to "Revoulution 9" by the Beatles. A collection of strung together sound clips and found noises, this recording features John Lennon repeating over and over "Number 9, Number 9..." Further, this song drew further attention in 1969 when it was discovered that when played backwards, John seemed to be saying "Turn me on, dead man..."
Therefore the ninth signal was destined to be the deadliest of the kill signals.
There’s a very long list of Unix signals, which you can view on Wikipedia. Somewhat confusingly, you can actually use kill to send any signal to a process. For instance, kill -SIGSTOP 12345 forces process 12345 to pause its execution, while kill -SIGCONT 12345 tells it to resume. A slightly less cryptic version of kill -9 is kill -SIGKILL.
I don't think there is any significance to number 9. In addition, despite common believe, kill is used not only to kill processes but also send a signal to a process.
If you are really curious you can read here and here.
why kill -9 :
the number 9 in the list of signals has been chosen to be SIGKILL in reference to "kill the 9 lives of a cat".
SIGKILL use to kill the process. SIGKILL can not be ignored or handled. In Linux, Ways to give SIGKILL.
kill -9 <process_pid>
kill -SIGKILL <process_pid>
killall -SIGKILL <process_name>
killall -9 <process_name>
Type the kill -l command on your shell
you will found that at 9th number [ 9) SIGKILL ], so one can use
either kill -9 or kill -SIGKILL
SIGKILL is sure kill signal, It can not be dis-positioned, ignore or handle.
It always work with its default behaviour, which is to kill the process.
The -9 is the signal_number, and specifies that the kill message sent should be of the KILL (non-catchable, non-ignorable) type.
kill -9 pid
Which is same as below.
kill -SIGKILL pid
Without specifying a signal_number the default is -15, which is TERM (software termination signal). Typing kill <pid> is the same as kill -15 <pid>.
Both are same as kill -sigkill processID, kill -9 processID.
Its basically for forced termination of the process.
there are some process which cannot be kill like this "kill %1" . if we have to terminate that process so special command is used to kill that process which is kill -9.
eg
open vim and stop if by using ctrl+z then see jobs and after apply kill process than this process will not terminated so here we use kill -9 command for terminating.
Related
Occasionally, for reasons I can not determine, ess-indent-or-complete sends an input to the R console. In other words, I will be typing something, hit tab to autocomplete (or company autocompletes for me), and the R process will update with a newline (.R file on the left "buffer", R process on the right):
x <- mea█ | >
|
|
... and then I hit tab to complete "mean":
x <- mean█ | >
| > ## note the new line here
|
This can be really annoying for at least two reasons:
It fills up the process buffer with blank lines.
If I am using a browser(), it advances lines which is often undesirable.
I have tried to diagnose this myself to no avail. Restarting emacs fixes it every time, however it seems to start happening at random throughout the day. Once it starts it does not stop until emacs restarts.
I am running emacs 27.1, ess-20210818.843 (though this has been a thing for a long time, so I don't believe it is version-specific), and am in ESS[R] mode.
Calling M-: (ess-command "") from my .R file buffer replicates the undesired behavior once it starts happening in a particular session. I have no insight beyond this.
I think you solved it yourself, with your GH issue suggestion:
https://github.com/emacs-ess/ESS/issues/1198
I've changed things in my own version of ESS, and will commit after a few days of testing it.
Thank you VERY VERY much for persevering and (I think) finding the fault .. a simple typo inside the internal (ess--command-make-restore-function)
I'm trying to profile an existing application with a quite complicated structure. For now I am using perf_event_open and the needed ioctl calls for enabling the events which are of my interest.
The manpage stays that PERF_COUNT_HW_INSTRUCTIONS should be used carefully - so which one should be preferred in case of a Skylake processor? Maybe a specific Intel PMU?
The perf_event_open manpage http://man7.org/linux/man-pages/man2/perf_event_open.2.html
says about PERF_COUNT_HW_INSTRUCTIONS:
PERF_COUNT_HW_INSTRUCTIONS Retired instructions. Be careful, these can be affected by various issues, most notably hardware interrupt counts.
I think this means that COUNT_HW_INSTRUCTIONS can be used (and it is supported almost everywhere). But exact values of COUNT_HW_INSTRUCTIONS for some code fragment may be slightly different in several runs due to noise from interrupts or another logic.
So it is safe to use events PERF_COUNT_HW_INSTRUCTIONS and PERF_COUNT_HW_CPU_CYCLES on most CPU. perf_events subsystem in Linux kernel will map COUNT_HW_CPU_CYCLES to some raw events more suitable to currently used CPU and its PMU.
Depending on your goals you should try to get some statistics on PERF_COUNT_HW_INSTRUCTIONS values for your code fragment. You can also check stability of this counter with several runs of perf stat with some simple program:
perf stat -e cycles:u,instructions:u /bin/echo 123
perf stat -e cycles:u,instructions:u /bin/echo 123
perf stat -e cycles:u,instructions:u /bin/echo 123
Or use integrated repeat function of perf stat:
perf stat --repeat 10 -e cycles:u,instructions:u /bin/echo 123
I have +-10 instructions events variation (less than 0.1%) for 200 thousands total instructions executed, so it is very stable. For cycles I have 5% variation, so it should be cycles event marked with careful warning.
I am writing a program with a named pipe with multiple readers and multiple writers. The idea is to use that named pipe to create pairs of reader/writer. That is:
A reads the pipe
B writes in the pipe
(vice versa)
Pair A-B created!
In order to ensure that only one process is reading and one is writing, I have used 2 locks with flock. Just like this.
Reader Code:
echo "[JOB $2, Part $REMAINING] Taking next machine..."
VMTAKEN=$((
flock -x 200;
cat $VMPIPE;
)200>$JOINQUEUELOCK)
echo "[JOB $2, Part $REMAINING] Machine $VMTAKEN taken..."
Writer Code:
((
flock -x 200;
echo "[MACHINE $MACHINEID] I am inside the critical section"
echo "$MACHINEID" > $VMPIPE;
echo "[MACHINE $MACHINEID] Going outside the critical section"
)200>$VMQUEUELOCK)
echo "[MACHINE $MACHINEID] Got new Job"
I sometimes get the following problem:
[MACHINE 3] I am inside the critical section
[JOB 1, Part 249] Taking next machine...
[MACHINE 3] Going outside the critical section
[MACHINE 1] I am inside the critical section
[MACHINE 1] Going outside the critical section
[MACHINE 1]: Got new Job
[MACHINE 3]: Got new Job
[JOB 1, Part 249] Machine 3
1 taken...
As you can see, Another writer wrote before the reader finished reading. What can I do to get rid of this problem? Should I use an ACK Pipe or something?
Thank you in advance
This would be a typical use for semaphores:
Create 2 semaphores - one for reading processed, the other one for writing processes. set each semaphore to value 1
Reading processes sem_wait(2) on the semaphore for readers until semphore > 0 and lower it to zero if they get it.
Writing processes will do the same with the semaphore intended for them
A controlling process (which may also set up the semaphores initially) could check, if both semaphores are zero and assign the pair
reader/writer release the semaphores (increasing them by 1 again) so next readr or writer will get the semaphore.
For passing informations between reader/writer shared memory may be used...
Fork is a great tool in unix.We can use it to generate our copy and change its behaviour.But I don't know the history of fork.
Does someone can tell me the story?
Actually, unlike many of the basic UNIX features, fork was a relative latecomer (a).
The earliest existence of multiple processes within UNIX consisted of a few (fixed number of) processes, one per terminal that was attached to the PDP-7 machine (b).
The basic idea was that the shell process for a given terminal would accept a command from the user, locate the program file, load a small bootstrap program into high memory and jump to it, passing enough details for the bootstrap code to load the program file.
The bootstrap code, after loading the program into low memory (overwriting the shell), would then jump to it.
When the program was finished, it would call exit but it wasn't like the exit we know and love today. This exit would simply reload the shell and run it using pretty much the same method used to load the program in the first place.
So it was really more like a rudimentary exec command, the one that replaces your current program with another, in the same process space.
The shell would exec your program then, when your program was done, it would again exec the shell by calling exit.
This method was similar to that found in many other interactive systems at the time, including the Multics from whence UNIX got its name.
From the two-way exec, it was actually not that big a leap to adding fork as a process duplicator to work in conjunction. While many systems run another program directly, it's this "just add what's needed" method which is responsible for the separation of duties between fork and exec in UNIX. It also resulted in a very simple fork function.
If you're interested in the early history of various features(c) of Unix, you cannot go past the article The Evolution of the Unix Time-Sharing System by Dennis Ritchie, presented at a 1979 conference in Australia, and subsequently published by AT&T.
(a) Though I mean latecomer in the sense that the separation of the four fundamental forces in the universe was "late", happening some 0.00000000001 seconds after the big bang.</humour>.
(b) Since a question was raised in a comment as to how the shells were originally started off, there's a great resource holding very early source code for Unix over at The Unix Heritage Society, specifically the source code archives and, in particular, the first edition.
The init.s file from the first edition shows how the fixed number of shell processes were created (slightly reformatted):
...
mov $itab, r1 / address of table to r1
1:
mov (r1)+, r0 / 'x, x=0, 1... to r0
beq 1f / branch if table end
movb r0, ttyx+8 / put symbol in ttyx
jsr pc, dfork / go to make new init for this ttyx
mov r0, (r1)+ / save child id in word offer '0, '1, etc
br 1b / set up next child
1:
...
itab:
'0; ..
'1; ..
'2; ..
'3; ..
'4; ..
'5; ..
'6; ..
'7; ..
0
Here you can see the snippet which creates the processes for each connected terminal. These are the days of hard-coded values, no auto detection of terminal quantity involved. The zero-terminated table at itab is used to create a number of processes and hopefully the comments from the code explain how (the only possibly tricky bit is the labels - though there are multiple 1 labels, you branch to the nearest one in a given direction, hence 1b means the closest 1 label in the backwards direction).
The code shown simply processes the table, calling dfork to create a process for each terminal and start getty, the login prompt. The getty program, in turn, eventually started the shell. From that point, it's as I described in the main part of this answer.
(c) No paths (and use of temporary links to get around this limitation), limited processes, why there's a GECOS field in the password file, and all sorts of other trivia, generally interesting only to uber-geeks, of course.
On OS X 10.4/5/6:
I have a parent process which spawns a child. I want to kill the parent without killing the child. Is it possible? I can modify source on either app.
As NSD asked, it really depends on how it is spawned. If you are using a shell script, for example, you can use the nohup command to run the child through.
If you are using fork/exec, then it is a little more complicated, but no too much so.
From http://code.activestate.com/recipes/66012/
import sys, os
def main():
""" A demo daemon main routine, write a datestamp to
/tmp/daemon-log every 10 seconds.
"""
import time
f = open("/tmp/daemon-log", "w")
while 1:
f.write('%s\n' % time.ctime(time.time()))
f.flush()
time.sleep(10)
if __name__ == "__main__":
# do the UNIX double-fork magic, see Stevens' "Advanced
# Programming in the UNIX Environment" for details (ISBN 0201563177)
try:
pid = os.fork()
if pid > 0:
# exit first parent
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# decouple from parent environment
os.chdir("/")
os.setsid()
os.umask(0)
# do second fork
try:
pid = os.fork()
if pid > 0:
# exit from second parent, print eventual PID before
print "Daemon PID %d" % pid
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# start the daemon main loop
main()
This is one of the best books ever written. It covers these topics in great and extensive detail.
Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series) (Paperback)
ISBN-10: 0321525949
ISBN-13: 978-0321525949
5 star amazon reviews (I'd give it 6).
If the parent is a shell, and you want to launch a long running process then logout, consider nohup (1) or disown.
If you control the coding of the child, you can trap SIGHUP and handling it in some non-default way (like ignoring it outright). Read the signal (3) and sigaction (2) man pages for help with this. Either way there are several existing questions on StackOverflow with good help.