From Newsgroup: comp.os.linux.misc

Wrote a short Python script that uses os.system() to
run 'top' ... redirecting the output to a file. We
then clean-up the weird chars in the file and append
it to an ongoing log file.

Run the script from the CL and it works perfectly.

Run it via root crontab though and the top redirect
file exists, but is EMPTY.

Tried it as an every-five-minutes thing direct from
root crontab. Re-did the script a bit to make it
into a daemon run as an @reboot from root crontab.

Both approaches, EMPTY results file. The '>' sort
of works, but nothing shows up IN it.

The line :
os.system("top -n 1 > topp.txt")
We then clean up weird chars and append it
to the real log file. DID check if there was
any output BEFORE the clean-ups. Nada.

I've tried firming up the path - but I do
an os.chdir() anyway using sys.argv[0] at
the top of the script anyhow. Regardless,
the 'top' output delivers NOTHING to the
dest file. DOES create it, but ...

So ... why doesn't this work ???

'top' is 'ubiquitous', nothing new there.

The different behavior from the CL vs crontab
is puzzling. Been screwing with this all day,
trying lots of little variants.

The unit crashes every so often, so I figured I'd
make a log of 'top' data to see if it was starting
to use lots more mem/cpu somewhere.

Target = Pi3 + PiOS (Deb)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <[email protected]> wrote:

Wrote a short Python script that uses os.system() to run 'top' ... redirecting the output to a file. We then clean-up the weird chars
in the file and append it to an ongoing log file.

Run the script from the CL and it works perfectly.

Run it via root crontab though and the top redirect file exists, but
is EMPTY.

...

The line :
os.system("top -n 1 > topp.txt")
We then clean up weird chars and append it to the real log file. DID
check if there was any output BEFORE the clean-ups. Nada.

I've tried firming up the path - but I do an os.chdir() anyway using sys.argv[0] at the top of the script anyhow. Regardless, the 'top'
output delivers NOTHING to the dest file. DOES create it, but ...

So ... why doesn't this work ???

Very likely because you overlooked the "batch" CLI argument:

-b :Batch-mode operation
Starts top in Batch mode, which could be useful for sending
output from top to other programs or to a file. In this mode,
top will not accept input and runs until the iterations limit
you've set with the `-n' command-line option or until killed.

'top' is 'ubiquitous', nothing new there.

Top also expects (in normal operation mode) to be connected to a tty so
it can receive input from a user. When run from a crontab there is no
tty, and top likely aborts when it finds that it's file descriptor zero
is not a tty. The batch mode argument is described in the man page in
such a way that it implies it turns off the "check that fd[0] is a tty"
test.

The different behavior from the CL vs crontab is puzzling. Been
screwing with this all day, trying lots of little variants.

It is not at all puzzling for anyone who understands the difference
between programs that expect tty's and those that don't.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 7/11/26 00:34, Rich wrote:

c186282 <[email protected]> wrote:

Wrote a short Python script that uses os.system() to run 'top' ...
redirecting the output to a file. We then clean-up the weird chars
in the file and append it to an ongoing log file.

Run the script from the CL and it works perfectly.

Run it via root crontab though and the top redirect file exists, but
is EMPTY.

...

The line :
os.system("top -n 1 > topp.txt")
We then clean up weird chars and append it to the real log file. DID
check if there was any output BEFORE the clean-ups. Nada.

I've tried firming up the path - but I do an os.chdir() anyway using
sys.argv[0] at the top of the script anyhow. Regardless, the 'top'
output delivers NOTHING to the dest file. DOES create it, but ...

So ... why doesn't this work ???

Very likely because you overlooked the "batch" CLI argument:

-b :Batch-mode operation
Starts top in Batch mode, which could be useful for sending
output from top to other programs or to a file. In this mode,
top will not accept input and runs until the iterations limit
you've set with the `-n' command-line option or until killed.

I'll try it ! :-)

Still weird the CL -vs- Crontab behavior is SO different
for such an old basic utility.

'top' is 'ubiquitous', nothing new there.

Top also expects (in normal operation mode) to be connected to a tty so
it can receive input from a user. When run from a crontab there is no
tty, and top likely aborts when it finds that it's file descriptor zero
is not a tty. The batch mode argument is described in the man page in
such a way that it implies it turns off the "check that fd[0] is a tty"
test.

The different behavior from the CL vs crontab is puzzling. Been
screwing with this all day, trying lots of little variants.

It is not at all puzzling for anyone who understands the difference
between programs that expect tty's and those that don't.

I do know there's a diff - but didn't expect it HERE.

BTW, tried both a conventional crontab entry AND one
with a "&" at the end - which usually launches an
independent process.

'Top' is USUALLY used as something that's constantly
running kinda like 'ping'. However the "-n" param lets
it do just ONE scan and then exit. Yea, there are other,
really grungy, ways to get similar info, but why re-invent
what's basically already there ???

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

In comp.os.linux.misc, c186282 <[email protected]> wrote:

Run the script from the CL and it works perfectly.

Run it via root crontab though and the top redirect
file exists, but is EMPTY.

The environment variables for cron jobs are usually nearly empty.
Anytime something works from the shell but not from cron, check
environment variables.

Here's a tip: your cron scripts should work with _no_ environment
variables at all. To run them that with, use `env -i`. When I run
`env -i top` I get _no_ output at all.

The "-b" option suggested in another post fixes the no output problem.

Elijah
------
top probably wants $TERM set when not in batch mode
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Yep ! The "-b" param fixed it !

I'd have thought "-n" would have IMPLIED "-b" - but
clearly they didn't write it that way.

Always weirdnesses.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sat, 11 Jul 2026 05:46:23 -0000 (UTC), Eli the Bearded wrote:

When I run `env -i top` I get _no_ output at all.

It needs the TERM environment variable to be defined:

env -i TERM=xterm top

produces a top display.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 7/11/26 01:46, Eli the Bearded wrote:

In comp.os.linux.misc, c186282 <[email protected]> wrote:

Run the script from the CL and it works perfectly.

Run it via root crontab though and the top redirect
file exists, but is EMPTY.

The environment variables for cron jobs are usually nearly empty.
Anytime something works from the shell but not from cron, check
environment variables.

Here's a tip: your cron scripts should work with _no_ environment
variables at all. To run them that with, use `env -i`. When I run
`env -i top` I get _no_ output at all.

The "-b" option suggested in another post fixes the no output problem.

Elijah
------
top probably wants $TERM set when not in batch mode

As just posted ... the "-b" DID fix my weird issue.

Kinda thought "-n" would just imply "-b" but they
didn't write the util that way.

Anyway, NOW I can get a better picture of why
my unit just kinda suddenly freezes. Store
about 250kb of logs, OUGHT to be enough to
see if there are any services/procs/etc
suddenly using too much CPU/mem.

DID write a service that reports temperature and
disk space over TCP ... looks normal until ...
nothing useful there. Do like client/server
stuff - that one done with very few lines
of Python because high performance was
not needed :-)

DID have the damned thing auto-rebooting
six times a day to TRY and get around this
problem. Even that didn't always work.
A reboot is NOT quite the same as a cold
power-cycle restart. My unit is in a kinda
awkward location so pulling the wall wart
requires EFFORT and I'm getting too old
for lots of effort :-)

DOES give a cool IR-unfiltered wide camera
view though. LIKE the funky colors, esp the
ultramarine sky :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 7/11/26 01:57, Lawrence D’Oliveiro wrote:

On Sat, 11 Jul 2026 05:46:23 -0000 (UTC), Eli the Bearded wrote:

When I run `env -i top` I get _no_ output at all.

It needs the TERM environment variable to be defined:

env -i TERM=xterm top

produces a top display.

Another good idea.

However adding the "-b" (batch) param seems
to have solved my particular problem here.

Will keep your suggestion in mind if I have
issues with other utils.

Always lots of weirdnesses, ain't there ?

For some reason I too often wind up wanting
to use standard utils in unconventional ways.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Fri, 10 Jul 2026 23:57:54 -0400, c186282 wrote:

Wrote a short Python script that uses os.system() to run 'top' ... redirecting the output to a file. We then clean-up the weird chars in
the file and append it to an ongoing log file.

I think we've been here before...

https://docs.python.org/3/library/subprocess.html

Yes, it's one of those hateful, newfangled functions that might work for
you.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 7/11/26 02:40, rbowman wrote:

On Fri, 10 Jul 2026 23:57:54 -0400, c186282 wrote:

Wrote a short Python script that uses os.system() to run 'top' ...
redirecting the output to a file. We then clean-up the weird chars in
the file and append it to an ongoing log file.

I think we've been here before...

https://docs.python.org/3/library/subprocess.html

Yes, it's one of those hateful, newfangled functions that might work for
you.

Um ... there are LOTS of 'monitoring' apps for Linux
at this point - just did a survey a couple of days
ago. Most are serious OVER-kill. They also tend to
record SO much shit that you'll never be able to find
YOUR particular problem in the mess.

Anyway, the "-b" param to 'top' did do the trick.
Still not sure why evoking from the CL is so different
from evoking via crontab - but that's how it is.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sat, 11 Jul 2026 22:54:10 -0400, c186282 wrote:

On 7/11/26 02:40, rbowman wrote:

On Fri, 10 Jul 2026 23:57:54 -0400, c186282 wrote:

Wrote a short Python script that uses os.system() to run 'top' ...
redirecting the output to a file. We then clean-up the weird chars in
the file and append it to an ongoing log file.

I think we've been here before...

https://docs.python.org/3/library/subprocess.html

Yes, it's one of those hateful, newfangled functions that might work
for you.

Um ... there are LOTS of 'monitoring' apps for Linux at this point -
just did a survey a couple of days ago. Most are serious OVER-kill.
They also tend to record SO much shit that you'll never be able to
find YOUR particular problem in the mess.

subprocess is not an app. It is the Python library that is recommended
rather than the older os.system and has more flexibility but you got
system to work so go in peace. It probably won't be deprecated and dropped
any time soon.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <[email protected]> wrote:

On 7/11/26 02:40, rbowman wrote:

On Fri, 10 Jul 2026 23:57:54 -0400, c186282 wrote:

Wrote a short Python script that uses os.system() to run 'top' ...
redirecting the output to a file. We then clean-up the weird chars in
the file and append it to an ongoing log file.

I think we've been here before...

https://docs.python.org/3/library/subprocess.html

Yes, it's one of those hateful, newfangled functions that might work for
you.

Um ... there are LOTS of 'monitoring' apps for Linux
at this point - just did a survey a couple of days
ago. Most are serious OVER-kill. They also tend to
record SO much shit that you'll never be able to find
YOUR particular problem in the mess.

Anyway, the "-b" param to 'top' did do the trick.
Still not sure why evoking from the CL is so different
from evoking via crontab - but that's how it is.

Because without -b, top expects to be connected to a tty. And when
running from a crontab, there is no tty. With no tty, top didn't
bother doing anything but exiting.

This is basic Unix 101 level stuff.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sat, 11 Jul 2026 05:57:16 -0000 (UTC), I wrote:

It needs the TERM environment variable to be defined:

env -i TERM=xterm top

produces a top display.

Of course, what value such a display might have in a batch job,
remains a questionable issue ...
--- Synchronet 3.22a-Linux NewsLink 1.2