commandlinefu.com is the place to record those command-line gems that you return to again and again.
Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.
If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/
You can sign-in using OpenID credentials, or register a traditional username and password.
First-time OpenID users will be automatically assigned a username which can be changed after signing in.
Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.
Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):
Subscribe to the feed for:
Piping ps into grep is mostly useless: ps has its own filter options like -u and -C
Pipes the header row of ps to STDERR, then greps for the command on the output of ps, removing the grep entry before that.
This shows all process (-e) and threads (-L) in full format (-F)
grep по ps aux
That is useful to discover the start time of process older than 1 day.
You can also run:
ls -ld /proc/PID
That's returning the creation date of the proc files from the process. Some users reported that this way might show you a wrong date since any other process like cron, for example, could change this date.
Inner "ps...grep..." command searches for a process matching the specified .
"lsof -p lists all file descriptors owned by . Includes open files, sockets, devices, etc...
Display all pid less the 300 processes info
How much memory is chrome sucking?
This version also attaches to new processes forked by the parent apache process. That way you can trace all current and *future* apache processes.
Did some research and found the previous command wrong, we don't kill a zombie but its parent. Just made some modifcation to khashmeshab's command.
Trick to avoid the form:
grep process | grep - v grep
Finding high memory usage report in human readable format.