Strange lsof behaviour, possible bug?
 

Why is it when I run:

lsof -p `ps aux | grep crond | grep -v grep | awk '{print $2}'`

I get the output expected, but when I run:

lsof -p `ps aux | grep bash | grep -v grep | awk '{print $2}'`

I get an error. Even more confusing is when I run:

ps aux | grep bash | grep -v grep | awk '{print $2}'

on its own I get the pid as expected and when I manually paste that pid into lsof -p it runs as expected also?

Am I the only one?

cg

Supplying multiple PID's. Lsof doesn't like that unless you use the correct syntax to string it together (-a).
Try "for pid in $(pgrep -f bash); do lsof -p $pid; done" or "pgrep -f bash|xargs -iP lsof -p 'P'" or lsof $(pgrep -f bash|awk '{print "-a -p " $1}')

Thanks for your workarounds, but I'm not so sure your reason for it not working is true, when I run:

ps aux | grep bash | grep -v grep | awk '{print $2}'

I get only one number?

cg

Post the *exact* error you get? Appending "2>&1|tee /tmp/log" to your command should save all output to /tmp/log for perusal/posting.

Here it is:

lsof: status error on 1541: No such file or directory
lsof 4.72
latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
usage: [-?abhlnNoOPRstUvV] [+|-c c] [+|-d s] [+D D] [+|-f]
[-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]]
[-p s] [+|-r [t]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names]
Use the ``-h'' option to get more help information.

It's worth noting that the number 1541 changes everytime I try to run the command and has no relation at all to the bash pid.

This happens on 5 different servers all running CentOS.

cg

Can anyone spot why this is?

cg

Yep, sure can. The backticks cause another instance of bash to be run, which means the command in the backticks returns two pids, causing the error.

:scratch:

I thought the backticks meant "execute this first" ?

cg

The backticks mean "start a new sub-shell, run this, and replace this with the results of that". But yes, it does get run first... just by a child process of the parent bash.

Ahh, I'm with you now - thanks for your help!

cg