1

I have a situation where I have a process, say script.pl (here it is), which seems to stick around in the output to ps auxw | grep script.pl, sometimes when load is heavy it sticks around for several minutes. This script is called 5-10 times a second by another process (this process does a nonblocking call to the script like this: System(/some/path/script.pl &)).

At first I was worried that this script was for some reason failing to complete in a timely fashion and thus slowing other things down. However, all the script does is write a message to another box via a TCP socket.

And that's where things get weird. 1) I can verify this socket operation (the only thing the script does) completes by viewing the logs on the other box -- it gets the message immediately and on time. 2) Even though I see many instances of (seemingly completed) script.pl instances in ps output, I do not see corresponding entries if I do something like top -n 1 | grep script.pl -- this seems to indicate script.pl isn't using any resources; in fact there are no instances at all of script.pl in this output.

So finally, are there any known issues with ps or the Perl interpreter that could lead to completed Perl scripts hanging around in ps output, but not top output?

Thanks!

EDIT: I changed the top command call to: top -n 1 -u script_pl_user | grep script.pl. Now the process shows up equally in both places. However, in top, it's showing CPU usage of 0.0% and no or very very very small memory usage. Why is script.pl sticking around even though its operations are verified to be completed?

3
  • 1
    top shows only n processes, where n depends on the terminal size. By default it's ordered by CPU usage, so you won't see processes which don't use the CPU too much. So why do you expect your script should be listed in this (truncated) top list? ps ax shows all processes.
    – mpy
    May 13, 2013 at 13:50
  • Yes. I've changed my top call to top -n 1 -u script_pl_user | grep script.pl. My main question remains, why is script.pl still showing up in top and ps even though the operation it was supposed to do is verified to be completed? Why are they sticking around?
    – kmarks2
    May 13, 2013 at 13:56

1 Answer 1

1

This is due to the mechanics of ps and top.

Top simply aggregates usage by PID, and the System call in Perl essentially uses the OS' native fork(), which creates a child process. Child processes have the same PID as the parent. ps enumerates all running processes. For instance, note that the same thing is true of Apache. If you do Top and find Apache, you'll see only one entry, but if you do a ps aux and find Apache in there, there are several entries with the same PID.

Really, top is meant to find the total resource usage of a program, so you don't want to see the amount each child is using, and ps is to find what programs are running, in detail, so you want to see all of the child processes.

2
  • Any idea why a process continues to show up for ps or top when the operation it was to complete is verified completed? Is it an issue maybe with the actual Perl binary doing the interpretation? Thanks.
    – kmarks2
    May 13, 2013 at 13:58
  • 1
    This is a link to what I suspect is going on. For some reason, I think that you're creating "zombies" because your child processes are not correctly terminating. This is an error in your Perl, not in the interpreter. I really don't know much Perl, so I can't give you much more than that, hopefully that link is helpful to you.
    – Seth Curry
    May 13, 2013 at 14:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .