Tag Info

Hot answers tagged

6

The top manpage gives the answer (in the "Process Status" description): w: S -- Process Status The status of the task which can be one of: ’D’ = uninterruptible sleep ’R’ = running ’S’ = sleeping ’T’ = traced or stopped ’Z’ = zombie Tasks shown as running should be more properly thought of as ’ready to run’ -- their ...


3

you can use killall to kill, or send any other signal, to a bunch of processes at once. One of the "filtering" options is the owner: killall --user name1 I don't like killall (using it on solaris can cause disaster). pkill is more portable pkill -u username


3

You are running a lot of extremely short-lived processes. You aren't going to see them much in the top output. Top measures system activity periodically (often once per second). At each refresh, it goes through the process list and collects statistics for each process. Depending on the luck of the draw of scheduling, there may be either zero or one ls ...


3

Would something like the following be OK? This assumes bash (for brace expansion) and GNU parallel. parallel -N0 -j0 -u yes ::: {1..10} The -j0 setting is there to make sure as many processes as parameters get started, and -u (ungroup) is there so that the output of each process is printed as soon as it is available (this matters in the case of yes, since ...


3

You can use xargs to separate them and execute killall for each one : echo $PROCESSES_TO_QUIT | xargs killall -9


3

Answering your question literally, here's one way to list the last PID displayed by lsof: lsof … | awk 'END {print $2}' Awk is a text processing language which reads input and processes it line by line. In the code, END {…} executes the code in the braces after the whole input is processed, and effectively operates on the last line. $2 is the second ...


3

Use pkill: pkill blob That would kill all processes matching the pattern blob. Another approach would be killall, but you should call it with -r so that the pattern is interpreted as a regex: killall -r blob


3

Well, this httpd process is either: An actual HTTP daemon, properly installed on your system: in this case, it's probably running monitored in a way that it gets automatically restarted when it goes down. You should use the proper (OS-specific) command to stop it; assuming init scripts, it would be something like /etc/init.d/httpd stop. Malware, running as ...


2

There's a little tool called screen which is able to do this from you. You can detach from a screen session and let it run in background so you can close the SSH connection. After reconnection you can reatach to the screen. http://thesystemadministrator.net/cpanel/how-to-install-and-use-screen-in-linux


2

If you only want the process ids, why not use pgrep: pgrep -u root init Or: pgrep -U root init Which switch you use (-u/-U) depends on what you want. The difference is, -u matches the effective uid and -U the real uid: The effective uid describes the user whose file access permissions are used by the process. The real uid is from the user who created ...


2

It sounds like you have two PIDs and you want to know if one is a descendent of the other. If so, you can use this: #!/bin/bash # Checks the process tree checking to see if PID $1 is an ancestor of # PID $2. Returns true/false (0/1). # (Needs error handling to determine if $1 and $2 are provided and both # are numeric. Left as an exercise for the ...


2

If you want to find all the background processes started from the current bash session, you can use the jobs builtin of bash. From help jobs: jobs: jobs [-lnprs] [jobspec ...] or jobs -x command [args] Display status of jobs. Lists the active jobs. JOBSPEC restricts output to that job. Without options, the status of all active jobs is displayed. On ...


2

jobs -l Lists process IDs of the active jobs


2

AFAIK, lsof has not been ported to cygwin. You could use the Microsoft netstat utility there: netstat -aon | awk '$1 == "TCP" && $4 == "LISTENING" && $2 ~ /:8000$/ {print $5}' | xargs kill


2

To run commands concurrently you can use the & command separator. ~$ command1 & command2 & command3 This will start command1, then runs it in the background. The same with command2. Then it starts command3 normally. The output of all commands will be garbled together, but if that is not a problem for you, that would be the solution. If you ...


2

@dhag certainly has a one-line answer, but the syntax makes my eyes hurt. :) Since you asked for a single command, and since the shell considers for-do-done a single (compound) command, I feel justified with this much more readable version: for i in {1..10}; do yes &; done Note that some shells automatically nice(2) background jobs, so if that's an ...


2

Can I resume them later on (from Home) knowing just their PID or something ? No, since the scripts are tied to the terminal from which you run them. However, you can run your scripts inside tmux or screen. You can then detach tmux / screen from the terminal, and re-attach to it later from home. This one of the main use cases for tmux and screen.


2

The scheduler doesn't care why a process is not currently runnable. The S state is used whenever the process has invoked a system call that requires an external event to complete; at this point it does not matter whether the system call itself caused the external event (e.g. a read call), or it just waits (e.g. select or poll). You can find out which ...


2

A zombie process is a process that has terminated (normally or abnormally) without its parent wait(2)-ing for it. It doesn't consume resources (aside from a PID) since it's already dead. Wikipedia has a decent explanation for all this.


1

The system uses a limited number of PIDs (2^16 I think). If all the PID slots are occupied, the system won't be able to create new processes. That is the reason you should take care to reap your zombies, especially if your program creates a lot of processes (e.g., if you're a forking server).


1

S means idle. S is for “sleep” — the only way for a process to be idle is to be waiting for some event to wake it up. A process that is waiting to be scheduled isn't idle: the reason it would be scheduled is that it has stuff to do. R means runnable, i.e. a process on the scheduler's queue, executing user land code (i.e. code from the process itself). A ...


1

Ps gives a similar description of process states PROCESS STATE CODES Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process: D uninterruptible sleep (usually IO) R running or runnable (on run queue) S ...


1

Since you tagged this as Linux: pgrep / pkill to the rescue: PID_OF_SUB_PROCESS1=$( pgrep -P $PID_OF_PROCESS1 ) pkill -P $PID_OF_PROCESS1


1

From setpgrp man page from Darwin/MacOS (BSD-based): If the calling process is not already a session leader, setpgrp() sets the process group ID of the calling process to that of the calling process. Any new session that this creates will have no controlling terminal. There's your answer.


1

Invoking an executable that you don't own is nothing remarkable. Most executables on the system belong to root, and running them does not give the user any extra privileges. It's only setuid executables that start with the effective UID set to the owner of the executable while the real UID remains the real UID of the invoking process. sudo is setuid root, ...


1

You sould start the screen session in you .zshrc without exec, just screen. exec replaces the current process with the new one. So, you will never get back to the original process because it doesn't exist anymore. If started without exec, pstree would then look similar to this (I added -p to pstree to show the PIDs for comprehension): ...


1

Maybe try killall: % export PROCESSES_TO_QUIT='puma rake ...' % export KILL_SIGNAL='killall -9 ' % eval $KILL_SIGNAL $PROCESSES_TO_QUIT


1

You should get all the PIDs and kill 'em all: kill $(ps -ef|grep -v grep |grep java |awk '{print $2}'|tr '\n' ' '); echo or make it more verbose: netikras@netikras-PC ~ $ #ps -ef |grep -v grep |grep java |while read line; do echo "$line" |awk '{$1=$3=$4=$5=$6=$7=""; print "Killing: "$0"\n"}'; kill $(echo $line|awk '{print $2}') && echo KILLED || ...


1

I don't think it's possible. Here's why. I took the naive approach, which was to add the pid of the process opening /dev/fuse to the meta data that fuse creates at mount time, struct fuse_conn. I then used that information to display a pid= field in the mount command. The patch is really simple: diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h index ...


1

I think you can use a combination of ps and lsof to get the information you want. The userspace application seems to always have the argument of the mount point as an argument. If you grep through your process list looking for commands with the mount point as an argument (e.g. ps -ef | egrep ' <mount>( |$)'), you should get all FUSE processes. Of ...



Only top voted, non community-wiki answers of a minimum length are eligible