Hot answers tagged ps
Turns out there's a solution found in keychain. $ ps aux | grep "[f]nord" By putting the brackets around the letter and quotes around the string you search for the regex, which says, "Find the character 'f' followed by 'nord'." But since you put the brackets in the pattern 'f' is now followed by ']', so grep won't show up in the results list. Neato!
Another option I use (especially just to look if a process is running) is the pgrep command. This will search for a matching process, but not list a grep line for the search. I like it because it is a quick way of search, without regexing or escaping anything. pgrep fnord
you could try pargs <PID> this gives you a list of all arguments or else use an other ps. If run as root (or any user with enough privileges for that matter) /usr/ucb/ps auxww will give you all arguments. Its part of SUNWscpu, "Source Compatibility, (Usr)"
The order the commands are run actually doesn't matter and isn't guaranteed. Leaving aside the arcane details of pipe(), fork(), dup() and execve(), the shell first creates the pipe, the conduit for the data that will flow between the processes, and then creates the processes with the ends of the pipe connected to them. The first process that is run may ...
In Linux, every process has several IDs associated with it, including: Process ID (PID) This is an arbitrary number identifying the process. Every process has a unique ID, but after the process exits and the parent process has retrieved the exit status, the process ID is freed to be reused by a new process. Parent Process ID (PPID) This is just the PID of ...
By default, htop lists each thread of a process separately, while ps doesn't. Turn off the display of threads: in the “Setup / Display options” menu, “Hide userlands threads”. This puts the following line in your ~/.htoprc (you can alternatively put it there manually): hide_userland_threads=1 (Also hide_kernel_threads=1, but it's 1 by default.)
Brackets appear around command names when the arguments to that command cannot be located. The ps(1) man page on FreeBSD explains why this typically happens to system processes and kernel threads: If the arguments cannot be located (usually because it has not been set, as is the case of system processes and/or kernel threads) the command name is printed ...
ps uses the uid when the username is longer than 8 characters.
Piped commands run concurrently. When you run ps | grep …, it's the luck of the draw (or a matter of details of the workings of the shell combined with scheduler fine-tuning deep in the bowels of the kernel) as to whether ps or grep starts first, and in any case they continue to execute concurrently. This is very commonly used to allow the second program to ...
The ideal solution is the one presented by BriGuy pgrep fnord But if you do not want to do that, you can just exclude all lines that matches with grep with: ps aux | grep -v grep | grep "fnord"
These are indeed the process states. Processes states that ps indicate are: D Uninterruptible sleep (usually IO) R Running or runnable (on run queue) S Interruptible sleep (waiting for an event to complete) T Stopped, either by a job control signal or because it is being traced. W paging (not valid since the 2.6.xx kernel) X dead (should never be seen) Z ...
Pretty much all Linuxes use GNU versions of the original core Unix commands like ps, which, as you've noted, supports both BSD and AT&T style options. Since your stated goal is only compatibility among Linuxes, that means the answer is, "It doesn't matter." Embedded and other very small variants of Linux typically use BusyBox instead of the GNU tools, ...
man ps in NOTES section. CPU usage is currently expressed as the percentage of time spent running during the entire lifetime of a process. This is not ideal, and it does not conform to the standards that ps otherwise conforms to. CPU usage is unlikely to add up to exactly 100%. And, guess you know, but you can also do: top -p <PID> ...
On Linux at least, you can also do: ps -o lstart= -p the-pid to have a more useful start time. The mtimes of the files in /proc on Linux (at least) are generally the date when those files were instantiated, which would be the first time something tried to access them or list the directory content. For instance: $ sh -c 'date +%T.%N; sleep 3; echo ...
When you run ps -ef | grep string, grep is displayed in the output because string matches [...] grep string. But, when you run ps -ef | grep [s]tring the line isn't displayed, because grep translates [s]tring to string, while ps outputs [...] grep [s]tring, and that doesn't match string
killing 0 isnt killing the pid 0. Instead it is an option in kill to kill all processes in the current group. With your command you are killing everything in the process group ID (GID) of the shell that issued the kill command. from the kill man page: pid... Specify the list of processes that kill should signal. Each pid can be one of five ...
You can control the columns that get output by ps. Note that the exact commandline does vary between the various flavours of Linux/Unix but I believe the following will do what you want. ps --no-headers -o pid,comm -C "ProgramXX" >> Data.txt The man page for ps(1) will list all of the options available to you.
From the manual: Sometimes the process args will be unavailable; when this happens, ps will instead print the executable name in brackets.
ps does not hide the password. Applications like mysql overwrite arguments list that they got. Please note, that there is a small time frame (possible extendible by high system load), where the arguments are visible to other applications until they are overwritten. Hiding the process to other users could help. In general it is much better to pass passwords ...
A session leader is a process where session id == process id. This sounds contrived, but the session id is inherited by child processes. Some operations within UNIX/Linux operate on process sessions, for example, negating the process id when sending to the kill system call or command. The most common use for this is when logging out of a shell. The OS ...
You should reduce the columns output by ps to the minimum, i.e. request only the username here - this simplifies further processing. For example: $ ps -eo user= will print the owner of all the currently running processes (= suppresses the header). An easy way to get the counts for each user: $ ps -eo user= | sort | uniq -c 1 dovecot 1 messagebus ...
a = show processes for all users u = display the process's user/owner x = also show processes not attached to a terminal By the way, man ps is a good resource. Historically, BSD and AT&T developed incompatible versions of ps. The options without a leading dash (as per the question) are the BSD style while those with a leading dash are AT&T Unix ...
The kernel is not required to keep track of command line arguments. When a program is started through the execve call, the kernel must copy the arguments into the process memory (so that they will be available as argv in a C program, for example). After that, the kernel can discard the memory used to store the initial command line arguments. The process is ...
Why use ps when you can do it easily with the top command? If you must use ps, try this: ps aux | sort -kr 3,3 | head -n 6 If you want something that's truly 'top'esq with constant updates, use watch watch "ps aux | sort -kr 3,3 | head -n 6"
The buffers and cache are dynamically sized. If processes need more space, then it is taken from the buffers and the cache. The key is to look at the second line ("-/+ buffers/cache"). Mem: 496 489 6 0 4 452 -/+ buffers/cache: 33 462 Notice that the free in the second line (462) is the ...
On Linux: if you know the PID, you can cat the cmdline file for that file. E.g.: cat /proc/PID/cmdline This will probably fail if the binary was moved after the program was started. And of course: lsof -n | grep PID | grep ' txt ' and: ls -la /proc/PID/exe which is a symbolic link to the executable.
That means one day + 4:38 hours of cumulative CPU time that has been used by this process. Example It's helpful to look at the column headers to understand the values. $ ps -ef | head -5 UID PID PPID C STIME TTY TIME CMD root 1 0 0 2013 ? 00:00:01 /sbin/init root 2 0 0 2013 ? 00:00:00 [kthreadd] ...
You can check the manpage using man ps to find out what the columns mean. The Linux ps manpage, for example, gives: c C integer value of the processor utilisation percentage. (see %cpu) tname TTY controlling tty (terminal). (alias tt, tty). args COMMAND command with all its ...
From the ps manpage: Processes marked <defunct> are dead processes (so-called "zombies") that remain because their parent has not destroyed them properly. These processes will be destroyed by init(8) if the parent process exits.
In zsh, grep fnord =(ps aux). The idea is, first run ps aux, put the result in a file, then use grep on that file. Only, we don't have a file, as we use zsh's "process substitution". To illustrate, try ps aux > ps.txt grep fnord ps.txt rm ps.txt The result should be the same. General comment on some of the other answers. Some are far to complicated ...
Only top voted, non community-wiki answers of a minimum length are eligible