I have a PID,but the process is not running anymore and has completed. I need to get the complete details associated with that PID.
Is it possible?
I am using Solaris 5.1 OS.
If the process is a zombie, then you can find it by
ps -ef |grep -i defunct
Otherwise(if the process isn't a zombie) there is no way to retrive the information
Related
When I want to kill a process using the pid in linux, its subprocess still existes. I hope to kill all process using one command.
Suggesting command pkill -p PID pattern .
See more documentation here.
Check out process groups:
https://en.wikipedia.org/wiki/Process_group
Assuming you want to do this from a shell?
If you do a kill and make the top process negative it does a killpg under the covers and sends the signal to all the processes in the group.
I had given a job in a remote server yesterday from my home. The command was
sh run.sh >& out &
The run.sh will excute a program (average.f) more than 1000 times recurssively.
Today, in my office, I found some mistake in my run.sh. So I would like to kill it.
I used top command, but it is not showing the run.sh. It is only showing average.f. So, once, I killed it with kill PID, it is again starting average.f with another PID and producing outputs.
ps -u is not showing either run.sh or average.f.
Can anybody please help me how to kill this job.
find your job id with the process or application name . example is given below - I am killing java process here
ps -aef|grep java
// the above command will give you pid, now fire below command to kill that job
kill -9 pid
// here pid is a number which you get from the first command
ps -ef | grep run.sh | grep -v grep | awk '{print $2}' | xargs kill -9
Use pstree(1) (probably as pstree -p) to list the process tree hierarchy, then kill(1) (first with -TERM, then with -QUIT, and if that does not work, at last with -KILL) your topmost shell process running run.sh (or else the few "higher" processes). Perhaps use killall(1) or pidof(1) (or pgrep(1) or pkill)
You might want to kill the process group, with a negative pid.
You should never at first kill -KILL a process (but only at last resort); some programs (e.g. database servers, sophisticated numerical computations with application checkpointing, ...) have installed a SIGTERM or SIGQUIT signal handler to clean up their mess and e.g. save some state (on the disk) in a sane way. If you kill -KILL them, they could leave the mess uncleaned (since SIGKILL cannot be caught, see signal(7)....)
BTW, you should use ps auxw to list all processes, read ps(1)
I tried checking on Google, but I couldn't find much information related to the actual question.
How do I get a consolidated list of zombie processes and daemon processes?
How do I do it on different operating systems. Linux? AIX? Windows?
I am sure that, based on PID, we cannot identify the type of process. Running through a terminal might not help either.
Try out this.
ps axo pid,ppid,pgrp,tty,tpgid,sess,comm |awk '$2==1' |awk '$1==$3'
In the above command I used the very properties of a daemon to filter them out, from all of existing processes in Linux.
The parent of a daemon is always Init, so check for ppid 1.
The daemon is normally not associated with any terminal, hence we have ‘?’ under tty.
The process-id and process-group-id of a daemon are normally same
The session-id of a daemon is same as it process id.
With GNU ps on Linux:
[
$ ps --version
procps-ng version 3.3.3
]
Zombies:
ps -lA | grep '^. Z'
will get you all zombies (note that the param is lowercase 'L', i.e., 'l' followed by 'A').
Daemons:
As #Barmar said there's no way to get daemons for certain, but a clue that a process is a daemon is that it's not associated with any TTY device. The 12th column of 'ps -Al' output is TTY; the 4th is PID, 14th is the process name. Hence:
ps -lA | awk '$12 == "?" {print $4, $14}'
will get you processes that are possibly daemons; not guaranteed! :)
Daemons are started by the init process, which means they have a PPID of 1.
Therefore:
ps -ef | awk '$3 == 1'
To get the list of Zombie and daemon process just write a psudo character dev driver, where you should navigate trough the task_struct and look for state
I wrote for daemons and the "old" sysv initd, you have to check if it is working on your distro.
Good demons have well written startup scripts in /etc/initd
When changing runlevel, how does init know the running daemons ?
It looks for their names in the directory
/var/lock/subsys
So you can
get the names list from there
scan all the running processes and check if the name is inside the list: bingo !
To scan all the processes: list every subdirectory in
/proc
If its name is digits, it is the pid of a running process.
For example, the status of the process with pid 1234 is this file
/proc/1234/status
Open it and get the first line, starts with "Name:"
See
http://man7.org/linux/man-pages/man5/proc.5.html
https://linuxexplore.com/2014/03/19/use-of-subsystem-lock-files-in-init-script/
I have a script that runs from a newly created shell.
OS is Red Hat Enterprise Linux Server release 5.4 (Tikanga).
In certain point when the script detects that some application (started by the script) is hanging the script tries to terminate all the procesess it started. I assumed that the correct command for terminating all processes started by current user in current shell is:
pkill /?
The problem is that it kills sshd that is started in parent shell (by init.d) and the putty console disconnects showing error message.
I wonder:
How is it possible for specific user in specific shell to terminate process started by other user in parent shell?
What would be correct command to terminate all processes started by the script currently running?
I have found some solution where i store all the PIDs and when the script needs to terminate them I run in the loop the following:
[ws#RHDev ~]# pkill $(ps aux | grep $pid | awk '{print $2}')
However, I am looking for one-liner that simply terminates all the processes started by the current script.
You can filter subprocesses by the current process pid. The ps command can do this using the --ppid parameter.
ps opid --ppid=7051 | tail -n +2 | xargs kill
here tail -n +2 is to strip the ps headers.
I assumed that the correct command for terminating all processes started by current user in current shell is:
pkill /?
This command matches every single process in the system because it effectively requires only 0 symbols from process name to match. pgrep -l /? demonstrates that.
How is it possible for specific user in specific shell to terminate process started by other user in parent shell?
From man kill(2):
For a process to have permission to send a signal it must either be
privileged (under Linux: have the CAP_KILL capability), or the real or
effective user ID of the sending process must equal the real or saved
set-user-ID of the target process. In the case of SIGCONT it suffices
when the sending and receiving processes belong to the same session.
Do you invoke pkill from user root?
What would be correct command to terminate all processes started by the script currently running?
When bash starts it creates its own process group. Child processes it creates are put in the same process group. Hence:
kill -- -$$
Kills all processes started by the current script. Provided that those processes didn't become group leaders.
How would I track the CPU and Ram usage for a process that may run, stop, and then re-run with a different PID?
I am looking to track this information for all processes on a Linux server but the problem is when the process stops and restarts, it will have a different PID and I am not sure how to identify it as the same process.
What you're looking for here is called "process accounting".
http://tldp.org/HOWTO/Process-Accounting/
If you know the command of the process, just pipe it to a grep like this:
ps ux | grep yourcommandgoeshere
You can setup a crontab to record output of commands like
top -b -n1 | grep
ps ux | grep
Alternatively, you can use sealion service. By simply installing agent and configuring it according to your needs in simple steps, you can see output of the executed commands online.
Hope it helps...