It's pid is increasing all the time...
I'm writing a program to display all the process's info, this process really bother me.
Oh..the Chinese words are sleeping...
, can't use
, can't use
2 Answers
Technically, it's not a single process whose pid is changing, but rather the old process is terminating, and a new one is starting.
Why not try to find its parent process id, e.g. using ps -o pid,ppid,cmd -U root
(it will be in the second column). It is possible there is a parent process that is starting all the other processes.
It seems strange that there is no name for that process in the first column. There may be more clues in the /proc directory, for example ls -l /proc/<pid>/exe
and cat /proc/<pid>/cmdline
. Also try the different ps
commands options, e.g. ps -o pid,comm
and ps -o pid,args
will print different information. (Add either -U root
or -p <pid>
to these commands.)
UPDATE
If the process has no name, maybe pgrep '^$'
will list it, then you can do whatever you like with it, e.g.
pgrep '^$' | while read pid; do
ps -f $pid
ls -l /proc/$pid/cmdline
netstat -tlp | grep '\<'$pid'\>'
echo kill $pid # remove the echo after testing
done
If pgrep '^$'
lists nothing, then maybe a normal ps -o comm= -U root | od -c
to understand what the process name is, so you can use pgrep
to find only processes with that name.
If that also fails, look into auditctl
.
Or you write a script that runs ps
twice and kills any processes that only appear in the second run's output.
Also, if it is a rootkit like others have suggested, it would be a good idea to disconnect that computer from the internet while you investigate. That way it can't send any of your personal data to other people, or send spams, or anything else like that.
-
Since the pid is changing very quickly, when I get the pid displayed on the screen and ls it in the /proc/<pid>, the <pid> directory has already been gone...– wong2Commented Mar 17, 2011 at 4:32
-
-
@briankb: pstree, if it ran fast enough and captured the data, would show the process as being a child of init. It's parent is dying right after the fork in each case, so it ends up having no parent. Commented Mar 17, 2011 at 18:05
My guess is that this process is part of a rootkit of some kind. It purposely does fork
and the old one dies very frequently in order to be hard to pin down and send a signal like SIGSTOP
or SIGKILL
to. The fact that it's missing a name also points to this being the case.
-
-
@wong2: Not any that I can think of. I really wish the kernel gave you a way to deal with this. Perhaps a way to intercept all
fork
calls by a process that has made at least 10 calls to fork in the last 10 seconds. Or just a way to intercept all fork calls and either approve them or deny them. Commented Mar 17, 2011 at 15:52