Wrapping prstat on Solaris

At work we currently use top to monitor ongoing system utilization on our
Solaris systems. As time has moved on though, use of top has become
problematic. Our admins want us to switch to prstat, Sun's top-like
command. It works fine however doesn't emit a timestamp at each display
interval, so it's essentially impossible looking at a prstat output
file to determine when the particular "screen" was emitted.

If figured, "No problem. I'll just write a little wrapper." Alas, that is
proving harder than I thought. I can run prstat directing output to a file
and it seems to blast out a block of lines every N seconds, but when run
from inside a Python script I can't seem to make the damn thing not
massively buffer its output. Accordingly, my script doesn't really see the
output as its emitted, so the timestamp line it prepends to a block of
output is off.

I'm currently using subprocess.Popen like so:

os.environ["TERM"] = "dumb"
cmd = "prstat -c %s" % " ".join(sys.argv[1:])
pipe = Popen(cmd, shell=True, bufsize=1, stdout=PIPE).stdout

I've tried these other variants as well:

* prefacing the prstat command with unbuffer (the tcl/expect thingamabob)

* explicitly redirect the prstat output to /dev/stdout

* setting bufsize to 0

* used os.popen instead of Subprocess.Popen

Nothing seems to help. I always seem to see about 30 seconds of data at
once (I'm currently using a 5-second interval and 10 lines of output). I
would have expected that prstat would simply flush stdout after each block
of output.

Any ideas about how to get prstat to cooperate better?

Thanks,

--
Skip Montanaro - - http://www.smontanaro.net/
That's more than a dress. That's an Audrey Hepburn movie. -- Jerry Maguire

skip@pobox.com

schrieb:
> At work we currently use top to monitor ongoing system utilization on our
> Solaris systems. As time has moved on though, use of top has become
> problematic. Our admins want us to switch to prstat, Sun's top-like
> command. It works fine however doesn't emit a timestamp at each display
> interval, so it's essentially impossible looking at a prstat output
> file to determine when the particular "screen" was emitted.
>
> If figured, "No problem. I'll just write a little wrapper." Alas, that is
> proving harder than I thought. I can run prstat directing output to a file
> and it seems to blast out a block of lines every N seconds, but when run
> from inside a Python script I can't seem to make the damn thing not
> massively buffer its output. Accordingly, my script doesn't really see the
> output as its emitted, so the timestamp line it prepends to a block of
> output is off.
>
> I'm currently using subprocess.Popen like so:
>
> os.environ["TERM"] = "dumb"
> cmd = "prstat -c %s" % " ".join(sys.argv[1:])
> pipe = Popen(cmd, shell=True, bufsize=1, stdout=PIPE).stdout
>
> I've tried these other variants as well:
>
> * prefacing the prstat command with unbuffer (the tcl/expect thingamabob)
>
> * explicitly redirect the prstat output to /dev/stdout
>
> * setting bufsize to 0
>
> * used os.popen instead of Subprocess.Popen
>
> Nothing seems to help. I always seem to see about 30 seconds of data at
> once (I'm currently using a 5-second interval and 10 lines of output). I
> would have expected that prstat would simply flush stdout after each block
> of output.
>
> Any ideas about how to get prstat to cooperate better?

Use pexpect, which will make the program believe it runs in a terminal,
and not buffer the output.

Diez

Diez B. Roggisch

On Jul 27, 10:26*am, s...@pobox.com wrote:
> At work we currently use top to monitor ongoing system utilization on our
> Solaris systems. *As time has moved on though, use of top has become
> problematic. *Our admins want us to switch to prstat, Sun's top-like
> command. *It works fine however doesn't emit a timestamp at each display
> interval, so it's essentially impossible looking at a prstat output
> file to determine when the particular "screen" was emitted.
>
> If figured, "No problem. *I'll just write a little wrapper." *Alas, that is
> proving harder than I thought. *I can run prstat directing output to a file
> and it seems to blast out a block of lines every N seconds, but when run
> from inside a Python script I can't seem to make the damn thing not
> massively buffer its output. *Accordingly, my script doesn't really see the
> output as its emitted, so the timestamp line it prepends to a block of
> output is off.
>
> I'm currently using subprocess.Popen like so:
>
> * * os.environ["TERM"] = "dumb"
> * * cmd = "prstat -c %s" % " ".join(sys.argv[1:])
> * * pipe = Popen(cmd, shell=True, bufsize=1, stdout=PIPE).stdout
>
> I've tried these other variants as well:
>
> * * prefacing the prstat command with unbuffer (the tcl/expect thingamabob)
>
> * * explicitly redirect the prstat output to /dev/stdout
>
> * * setting bufsize to 0
>
> * * used os.popen instead of Subprocess.Popen
>
> Nothing seems to help. *I always seem to see about 30 seconds of data at
> once (I'm currently using a 5-second interval and 10 lines of output). *I
> would have expected that prstat would simply flush stdout after each block
> of output.
>
> Any ideas about how to get prstat to cooperate better?
>
> Thanks,
>
> --
> Skip Montanaro - s...@pobox.com -http://www.smontanaro.net/
> * * That's more than a dress. That's an Audrey Hepburn movie. -- Jerry Maguire

Hey Skip,

You haven't told us how you are actually reading from prstat's output
pipe, which may be the cause. For instance, if you are doing

for line in pipe:
print line
...

then this could cause your buffering issue.

Instead try using readline():

while True:
line = pipe.readline()
...

ryles

> You haven't told us how you are actually reading from prstat's output
> pipe, which may be the cause. For instance, if you are doing
>
> for line in pipe:
> print line
> ...
>
> then this could cause your buffering issue.
>
> Instead try using readline():
>
> while True:
> line = pipe.readline()
> ...

Yes, I've been using for line in pipe. Switching to your construct
seems to work like a charm.

Thanks,

Skip

Skip Montanaro