How to know cmdline for a pid. (no ps, no top, no /proc)

damade · 02-03-2011, 07:00 AM

Hi all !!!
A few days ago i had to deal with a very odd situation.
Ps hanged. Top hanged. i discovered a pid which seems to block the execution of this commands.
I needed to know which was the process behind that pid. But when trying to access /proc/$pid/ session hanged.

I suppose this problem to access /proc/$pid cause the hang of the other commands (ps,top, etc)

How can i know info about a pid if i can't access data on /proc ?

thanks

unSpawn · 02-03-2011, 06:41 PM

Userland processes depend on /proc being available. If you know what to look for a 'grep -a {someSearchTerm} /proc/[0-9]*/cmdline' can give you info. But obviously no realtime process stats unless you query the other related proc/{pid}/* entries. If you want to troubleshoot the issue here then listing (if relevant) HW specs, kernel version, applications, knowing which changes were made before this behaviour appeared and checking system and daemon logs and posting exact error messages may help.

damade · 02-04-2011, 06:13 AM

'grep -a {someSearchTerm} /proc/[0-9]*/cmdline' would hang the session. because every command trying to read data on /proc/$pid was hanging.

Some fellow told me it was a command to read that info in the kernel memory (not /proc) but he dont know how to use it.

someone know it ?

unSpawn · 02-04-2011, 11:04 AM

Quote:

Originally Posted by damade

'grep -a {someSearchTerm} /proc/[0-9]*/cmdline' would hang the session. because every command trying to read data on /proc/$pid was hanging.

You know that for a fact because:
- you straced your "ps,top, etc" commands previously to show blocked syscalls?
- you actually tried grep and the strace shows the reasons why it wouldn't work?
If so posting strace results may be interesting. If you didn't: bummer. No "evidence". Regardless I think you should try to find out what changed on the system that causes hangs.