killall gives me `no process found ` but ps
Clash Royale CLAN TAG#URR8PPP
Could somebody explain to me the difference between kill
and killall
? Why doesn't killall
see what ps
shows?
# ps aux |grep db2
root 1123 0.0 0.8 841300 33956 pts/1 Sl 11:48 0:00 db2wdog
db2inst1 1125 0.0 3.5 2879496 143616 pts/1 Sl 11:48 0:02 db2sysc
root 1126 0.0 0.6 579156 27840 pts/1 S 11:48 0:00 db2ckpwd
root 1127 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
root 1128 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
# killall db2ckpwd
db2ckpwd: no process found
# kill -9 1126
# kill -9 1127
# kill -9 1128
System is SuSe 11.3 (64 bit); kernel 2.6.34-12; procps version 3.2.8; killall from PSmisc 22.7; kill from GNU coreutils 7.1
linux process kill ps
add a comment |
Could somebody explain to me the difference between kill
and killall
? Why doesn't killall
see what ps
shows?
# ps aux |grep db2
root 1123 0.0 0.8 841300 33956 pts/1 Sl 11:48 0:00 db2wdog
db2inst1 1125 0.0 3.5 2879496 143616 pts/1 Sl 11:48 0:02 db2sysc
root 1126 0.0 0.6 579156 27840 pts/1 S 11:48 0:00 db2ckpwd
root 1127 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
root 1128 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
# killall db2ckpwd
db2ckpwd: no process found
# kill -9 1126
# kill -9 1127
# kill -9 1128
System is SuSe 11.3 (64 bit); kernel 2.6.34-12; procps version 3.2.8; killall from PSmisc 22.7; kill from GNU coreutils 7.1
linux process kill ps
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57
add a comment |
Could somebody explain to me the difference between kill
and killall
? Why doesn't killall
see what ps
shows?
# ps aux |grep db2
root 1123 0.0 0.8 841300 33956 pts/1 Sl 11:48 0:00 db2wdog
db2inst1 1125 0.0 3.5 2879496 143616 pts/1 Sl 11:48 0:02 db2sysc
root 1126 0.0 0.6 579156 27840 pts/1 S 11:48 0:00 db2ckpwd
root 1127 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
root 1128 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
# killall db2ckpwd
db2ckpwd: no process found
# kill -9 1126
# kill -9 1127
# kill -9 1128
System is SuSe 11.3 (64 bit); kernel 2.6.34-12; procps version 3.2.8; killall from PSmisc 22.7; kill from GNU coreutils 7.1
linux process kill ps
Could somebody explain to me the difference between kill
and killall
? Why doesn't killall
see what ps
shows?
# ps aux |grep db2
root 1123 0.0 0.8 841300 33956 pts/1 Sl 11:48 0:00 db2wdog
db2inst1 1125 0.0 3.5 2879496 143616 pts/1 Sl 11:48 0:02 db2sysc
root 1126 0.0 0.6 579156 27840 pts/1 S 11:48 0:00 db2ckpwd
root 1127 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
root 1128 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd
# killall db2ckpwd
db2ckpwd: no process found
# kill -9 1126
# kill -9 1127
# kill -9 1128
System is SuSe 11.3 (64 bit); kernel 2.6.34-12; procps version 3.2.8; killall from PSmisc 22.7; kill from GNU coreutils 7.1
linux process kill ps
linux process kill ps
edited Jun 6 '11 at 13:59
Caleb
51.1k9149192
51.1k9149192
asked Jun 6 '11 at 2:48
RadekRadek
1,138142946
1,138142946
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57
add a comment |
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57
add a comment |
4 Answers
4
active
oldest
votes
Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps
, killall
, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u
; and 2) the short command name, which is what you get when you run ps
without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat
:
#!/bin/sh
cat
After running it, here's the two different types of ps
.
Firstly, without u
:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u
:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh
?
Now, as far as I can tell, killall
actually reads /proc/<pid>/stat
, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall
. Logically, that should be the same as what ps
without the u
flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat
say the command name is? - what does
ps -e | grep db2
say the command name is? - do
ps -e | grep db2
andps au | grep db2
show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm
to see the short name and ps -o cmd
to see the long name.
You also might find pkill
a better alternative. In particular, pkill -f
tries to match using the full command name, i.e. the command name as printed by ps u
or ps -o cmd
.
very good explanation. And I guess you were right the first time.ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives meroot 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.
– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What doesls -l /proc/3084/exe
say? What aboutwhich
orwhence
ortype
to find the file and thenls
andtype
to see if it's a symlink or a script or a binary?
– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives uslrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
|
show 1 more comment
killall tries to match on a process name (but is not really that good at the matching part).
And since "ps | grep" and "ps | grep | kill" does a much better job, someone simplified this and created pgrep and pkill. Read that commands like "ps grep" and "ps kill", since that command first ps then grep and if wanted kills.
add a comment |
I had a similar problem but /proc/<pid>/stat
contained the expected string. By using strace I could see that killall also accessed /proc/<pid>/cmdline
.
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc/<pid>/cmdline
. It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn't fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.
The source code of pkill
can be found here https://github.com/acg/psmisc for the interested.
add a comment |
On Ubuntu 16 systems the /proc/pid/stat will contain the name of the thread (which a program can via pthread_setname_np system call.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14479%2fkillall-gives-me-no-process-found-but-ps%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps
, killall
, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u
; and 2) the short command name, which is what you get when you run ps
without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat
:
#!/bin/sh
cat
After running it, here's the two different types of ps
.
Firstly, without u
:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u
:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh
?
Now, as far as I can tell, killall
actually reads /proc/<pid>/stat
, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall
. Logically, that should be the same as what ps
without the u
flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat
say the command name is? - what does
ps -e | grep db2
say the command name is? - do
ps -e | grep db2
andps au | grep db2
show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm
to see the short name and ps -o cmd
to see the long name.
You also might find pkill
a better alternative. In particular, pkill -f
tries to match using the full command name, i.e. the command name as printed by ps u
or ps -o cmd
.
very good explanation. And I guess you were right the first time.ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives meroot 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.
– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What doesls -l /proc/3084/exe
say? What aboutwhich
orwhence
ortype
to find the file and thenls
andtype
to see if it's a symlink or a script or a binary?
– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives uslrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
|
show 1 more comment
Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps
, killall
, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u
; and 2) the short command name, which is what you get when you run ps
without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat
:
#!/bin/sh
cat
After running it, here's the two different types of ps
.
Firstly, without u
:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u
:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh
?
Now, as far as I can tell, killall
actually reads /proc/<pid>/stat
, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall
. Logically, that should be the same as what ps
without the u
flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat
say the command name is? - what does
ps -e | grep db2
say the command name is? - do
ps -e | grep db2
andps au | grep db2
show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm
to see the short name and ps -o cmd
to see the long name.
You also might find pkill
a better alternative. In particular, pkill -f
tries to match using the full command name, i.e. the command name as printed by ps u
or ps -o cmd
.
very good explanation. And I guess you were right the first time.ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives meroot 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.
– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What doesls -l /proc/3084/exe
say? What aboutwhich
orwhence
ortype
to find the file and thenls
andtype
to see if it's a symlink or a script or a binary?
– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives uslrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
|
show 1 more comment
Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps
, killall
, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u
; and 2) the short command name, which is what you get when you run ps
without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat
:
#!/bin/sh
cat
After running it, here's the two different types of ps
.
Firstly, without u
:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u
:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh
?
Now, as far as I can tell, killall
actually reads /proc/<pid>/stat
, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall
. Logically, that should be the same as what ps
without the u
flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat
say the command name is? - what does
ps -e | grep db2
say the command name is? - do
ps -e | grep db2
andps au | grep db2
show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm
to see the short name and ps -o cmd
to see the long name.
You also might find pkill
a better alternative. In particular, pkill -f
tries to match using the full command name, i.e. the command name as printed by ps u
or ps -o cmd
.
Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps
, killall
, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u
; and 2) the short command name, which is what you get when you run ps
without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat
:
#!/bin/sh
cat
After running it, here's the two different types of ps
.
Firstly, without u
:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u
:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh
?
Now, as far as I can tell, killall
actually reads /proc/<pid>/stat
, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall
. Logically, that should be the same as what ps
without the u
flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat
say the command name is? - what does
ps -e | grep db2
say the command name is? - do
ps -e | grep db2
andps au | grep db2
show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm
to see the short name and ps -o cmd
to see the long name.
You also might find pkill
a better alternative. In particular, pkill -f
tries to match using the full command name, i.e. the command name as printed by ps u
or ps -o cmd
.
edited Jun 6 '11 at 4:31
answered Jun 6 '11 at 4:24
MikelMikel
39.6k10100126
39.6k10100126
very good explanation. And I guess you were right the first time.ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives meroot 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.
– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What doesls -l /proc/3084/exe
say? What aboutwhich
orwhence
ortype
to find the file and thenls
andtype
to see if it's a symlink or a script or a binary?
– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives uslrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
|
show 1 more comment
very good explanation. And I guess you were right the first time.ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives meroot 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.
– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What doesls -l /proc/3084/exe
say? What aboutwhich
orwhence
ortype
to find the file and thenls
andtype
to see if it's a symlink or a script or a binary?
– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives uslrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
very good explanation. And I guess you were right the first time.
ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives me root 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.– Radek
Jun 6 '11 at 4:33
very good explanation. And I guess you were right the first time.
ps -e |grep db2 gives me
3084 ? 00:00:00 db2syscr` and ps aux |grep db2 gives me root 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd
. Could comment on that. I am bit lost.– Radek
Jun 6 '11 at 4:33
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What does
ls -l /proc/3084/exe
say? What about which
or whence
or type
to find the file and then ls
and type
to see if it's a symlink or a script or a binary?– Mikel
Jun 6 '11 at 6:35
I'm not sure. It's possible that the program is changing its name. Do you know how it's being run? What does
ls -l /proc/3084/exe
say? What about which
or whence
or type
to find the file and then ls
and type
to see if it's a symlink or a script or a binary?– Mikel
Jun 6 '11 at 6:35
ls -l /proc/3084/exe gives us
lrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /proc/3084/exe gives us
lrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:52
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me
-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
ls -l /var/lib/db2/db2inst1/sqllib/adm/db2syscr gives me
-r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr*
– Radek
Jun 6 '11 at 6:53
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr
/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
type gives me /var/lib/db2/db2inst1/sqllib/adm/db2syscr
/var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr
– Radek
Jun 6 '11 at 6:54
|
show 1 more comment
killall tries to match on a process name (but is not really that good at the matching part).
And since "ps | grep" and "ps | grep | kill" does a much better job, someone simplified this and created pgrep and pkill. Read that commands like "ps grep" and "ps kill", since that command first ps then grep and if wanted kills.
add a comment |
killall tries to match on a process name (but is not really that good at the matching part).
And since "ps | grep" and "ps | grep | kill" does a much better job, someone simplified this and created pgrep and pkill. Read that commands like "ps grep" and "ps kill", since that command first ps then grep and if wanted kills.
add a comment |
killall tries to match on a process name (but is not really that good at the matching part).
And since "ps | grep" and "ps | grep | kill" does a much better job, someone simplified this and created pgrep and pkill. Read that commands like "ps grep" and "ps kill", since that command first ps then grep and if wanted kills.
killall tries to match on a process name (but is not really that good at the matching part).
And since "ps | grep" and "ps | grep | kill" does a much better job, someone simplified this and created pgrep and pkill. Read that commands like "ps grep" and "ps kill", since that command first ps then grep and if wanted kills.
answered Jun 6 '11 at 13:12
JohanJohan
3,29411728
3,29411728
add a comment |
add a comment |
I had a similar problem but /proc/<pid>/stat
contained the expected string. By using strace I could see that killall also accessed /proc/<pid>/cmdline
.
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc/<pid>/cmdline
. It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn't fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.
The source code of pkill
can be found here https://github.com/acg/psmisc for the interested.
add a comment |
I had a similar problem but /proc/<pid>/stat
contained the expected string. By using strace I could see that killall also accessed /proc/<pid>/cmdline
.
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc/<pid>/cmdline
. It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn't fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.
The source code of pkill
can be found here https://github.com/acg/psmisc for the interested.
add a comment |
I had a similar problem but /proc/<pid>/stat
contained the expected string. By using strace I could see that killall also accessed /proc/<pid>/cmdline
.
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc/<pid>/cmdline
. It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn't fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.
The source code of pkill
can be found here https://github.com/acg/psmisc for the interested.
I had a similar problem but /proc/<pid>/stat
contained the expected string. By using strace I could see that killall also accessed /proc/<pid>/cmdline
.
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc/<pid>/cmdline
. It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn't fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.
The source code of pkill
can be found here https://github.com/acg/psmisc for the interested.
answered Aug 15 '14 at 14:45
ZitraxZitrax
1805
1805
add a comment |
add a comment |
On Ubuntu 16 systems the /proc/pid/stat will contain the name of the thread (which a program can via pthread_setname_np system call.
add a comment |
On Ubuntu 16 systems the /proc/pid/stat will contain the name of the thread (which a program can via pthread_setname_np system call.
add a comment |
On Ubuntu 16 systems the /proc/pid/stat will contain the name of the thread (which a program can via pthread_setname_np system call.
On Ubuntu 16 systems the /proc/pid/stat will contain the name of the thread (which a program can via pthread_setname_np system call.
answered Jan 29 at 21:47
gerardwgerardw
1011
1011
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14479%2fkillall-gives-me-no-process-found-but-ps%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Never kill processes with SIGKILL (-9).
– vonbrand
Jan 23 '13 at 15:50
What to do then when a process needs to terminated?
– Radek
Jan 23 '13 at 22:28
This is the very, very last resort.
– vonbrand
Jan 23 '13 at 23:57