Why does `kill %jobnumber` not work on stopped jobs?
I'm running a few tasks side by side on an Ubuntu 18 LTS system. So I'm switching between these jobs by running:
# command &
# fg
# fg -I'm also using Ctrl+Z sometimes to send a running job to the background.
Say I have 3 jobs in my list:
# jobs
[1]+ Stopped nano /etc/nginx/site-available/blog.conf
[2] Stopped top
[3]- Stopped nano script.shI can successfully switch between these, but when I run the kill command on these, the jobs still show in the list. None gets killed. Why?
# kill %1I list again, and the jobs are still there:
# jobs
[1]+ Stopped nano /etc/nginx/site-available/blog.conf
[2] Stopped top
[3]- Stopped nano script.shPS: I can kill jobs with their process IDs, but why not with kill %1?
2 Answers
There is couple of things to point out here:
killwithout any arguments sends aSIGTERMsignal to the desired process or job identifier.SIGTERMcan be ignored by the process receiving it.A process which has been stopped (revived a
SIGSTOPfor example using Ctrl+z) can't do anything (saving a file, etc).
When you run kill without an argument on a process which needs specefic steps to get closed but cant (because it's stopped) it does not response to the SIGTERM and ignores it. at the other hand SIGKILL can not be ignored so it kills the process. that's why a command like sleep can be terminated with kill %1 just fine but a program like nano can not.
If you could not kill process by its PID, then you could not kill it using its job's identifier.
To kill process using its job's identifier without saving data, closing session operations and so on, use:
kill -9 %1kill sends signal number 15 (SIGTERM) to process, which could be ignored by process as it is in our case, because of it is stopped and, maybe, rejects to listen SIGTERM in stopped state. But signal number 9 (SIGKILL) is sent by kernel and it does not care if process could hear or not. It just ends it forcefully.
