Truncated ps

[Sylvain CROUET]

Hi!

To verify if processes are running I use the ps command redirected in a file (ps -exf > file). After some false positives I discovered that sometimes the output of the ps command was truncated after a process without name (see example below).
Have somebody any idea to explain that?

root 2936 1 0 Sep 1 ? 0:25 /usr/sbin/stm/uut/bin/tools/monitor/dm_stape
root 3009 1 0 Sep 1 ? 2:44 /usr/sbin/stm/uut/bin/tools/monitor/lpmc_em
root 2989 1362 0 Sep 1 ? 0:58 /opt/perf/bin/agdbserver -t alarmgen /var/opt/perf/datafiles/
root 14226 14195 1 19:35:56 ? 0:00

[Stefan Farrelly]

Ive checked these same processes on my servers and get same output - I dont believe they are not chopped off. There is no more output to display.

eg. /opt/perf/bin/agdbserver -t alarmgen /var/opt/perf/datafiles

is the complete command this process was started with - nothing is missing.

[Steven Gillard_2]

I assume you're talking about the last process in this list (pid 14226) with no command listed at all.

It is actually possible for applications to change their "process title" as it appears in the "args" field of ps -ef output by using an undocumented option to the pstat() system call. Sendmail and Oracle do this all the time so you can see what the processes are up to.

In your case you've got a program that looks like is setting its process title to an empty string. It *could* also be a small bug in the program thats not calling the exec() system call properly. Try the following:

* Check what the processes parent is (pid 14195). Something is spawning these "unnamed" processes and hopefully it has a name.

* Run ps without the -f argument (ie just ps -e). That will give you the basename of the command running instead of its full command line arguments.

* Use lsof to find out the full path to the program that is running. This is the line marked with "txt" as the fd.

That should tell you what the process is and you can go from there.

Regards,
Steve

[T G Manikandan]

It is defined here as COMMAND field to 64 characters
/usr/include/sys/pstat.h:
#define PST_CLEN 64

If you are running 11.0

load this patch

http://www1.itrc.hp.com/service/patch/patchDetail.do?patchid=PHCO_26274&context=hpux:800:11:00

If you are running 11i

just use the -x option
#ps -efx


Thanks

[Sylvain CROUET]

Following Steven idea I tried this command:
ps -exf > file1 & ps -ef > file2
As the problem happens randomly I have waited a while and when it happened file1 was incomplete and file 2 was complete. The process corresponding to the last one of file1 was 'cp'.
May it be possible that ps has a bug with the -x option ?

[Todd McDaniel_1]

I noticed that you are using ps without grepping anyting...I would use grep to pick out the named processes you are interested in.

My guess is the output of ps is truncated b/c your output is to long or is not being full captured by > file1...



I would try:

ps -exf |grep >file1

I will bet you will see the full ps listed.

[Sylvain CROUET]

Well, I do not use any grep command directly after the ps command, but do use grep commands on the ps generated file. As I look for several processes with the same script, I do not want to run the ps command too often.

[Todd McDaniel_1]

my point is that there may be a buffer overflow when capturing the whole ps -exf output...

By only grepping out what processes you are interested in, you will ensure that will not happen and probably prevent the truncation of your output.

:)

[Scot Bean · Accepted solution]

Sounds like you are running 11.11.

If so, check out 'ps' cmd patch PHCO_29042, released July2003.

There is a defect in 'ps -x' fixed in this patch that sounds like what you describe.