Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #88833 > unrolled thread

Something Odd - "top" Delivers Nada When Run By Crontab

Back to article view | Back to comp.os.linux.misc

Contents

  Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-10 23:57 -0400
    Re: Something Odd - "top" Delivers Nada When Run By Crontab Rich <rich@example.invalid> - 2026-07-11 04:34 +0000
      Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-11 01:38 -0400
        Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-11 01:51 -0400
    Re: Something Odd - "top" Delivers Nada When Run By Crontab Eli the Bearded <*@eli.users.panix.com> - 2026-07-11 05:46 +0000
      Re: Something Odd - "top" Delivers Nada When Run By Crontab Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-11 05:57 +0000
        Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-11 02:08 -0400
        Re: Something Odd - "top" Delivers Nada When Run By Crontab Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 06:46 +0000
          Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-12 22:10 -0400
      Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-11 02:04 -0400
    Re: Something Odd - "top" Delivers Nada When Run By Crontab rbowman <bowman@montana.com> - 2026-07-11 06:40 +0000
      Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-11 22:54 -0400
        Re: Something Odd - "top" Delivers Nada When Run By Crontab rbowman <bowman@montana.com> - 2026-07-12 03:00 +0000
          Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-12 19:23 -0400
        Re: Something Odd - "top" Delivers Nada When Run By Crontab Rich <rich@example.invalid> - 2026-07-12 03:36 +0000
          Re: Something Odd - "top" Delivers Nada When Run By Crontab c186282 <c186282@nnada.net> - 2026-07-12 19:25 -0400
            Re: Something Odd - "top" Delivers Nada When Run By Crontab The Natural Philosopher <tnp@invalid.invalid> - 2026-07-13 10:01 +0100

#88833 — Something Odd - "top" Delivers Nada When Run By Crontab

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)

[toc] | [next] | [standalone]

#88835

c186282 <c186282@nnada.net> 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.

[toc] | [prev] | [next] | [standalone]

#88836

On 7/11/26 00:34, Rich wrote:
> c186282 <c186282@nnada.net> 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 ???

[toc] | [prev] | [next] | [standalone]

#88838

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.

[toc] | [prev] | [next] | [standalone]

#88837

In comp.os.linux.misc, c186282  <c186282@nnada.net> 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

[toc] | [prev] | [next] | [standalone]

#88839

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.

[toc] | [prev] | [next] | [standalone]

#88841

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.

[toc] | [prev] | [next] | [standalone]

#88848

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 ...

[toc] | [prev] | [next] | [standalone]

#88855

On 7/12/26 02:46, Lawrence D’Oliveiro wrote:
> 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 ...

   It was reliably explained that 'top', as
   normally used, expects a terminal. The
   "-b" is by the docs the "non-interactive"
   mode and does not expect a terminal.

   Fixed MY little weirdness.

   Some/many CL utils work fine from a terminal
   or from crontab. 'Top' is not one of those.

   In any case, I thank those who provided the
   easy fix. Now my stuff works fine. Still need
   to clean-up the output a bit more, it's large
   and kinda confusing. Still better than NO
   output though !

   Some wondered why I was using os.system() with
   output redirected to a file rather than
   'subprocess' with it's weird lists for both
   input and output, sometimes 'b'inary that
   require translation. It's the KISS principle.
   Fewer, simpler, lines to save to a temp file,
   then open/clean that data.

   Sometimes "better" just ain't.

   Heh ... have a pgm that calls 'ffmpeg', with
   about 15 params. The 'subprocess' shit mostly
   requires composing a huge nasty list of all
   the params just to CALL the damned util. UGLY !
   Never sure when the param and follow-on value
   need to be ONE item in the list or not - takes
   like 99 experiments. Os.system() - you simply provide
   a pretty standard ascii line, like you were typing
   from terminal, and it JUST WORKS.

[toc] | [prev] | [next] | [standalone]

#88840

On 7/11/26 01:46, Eli the Bearded wrote:
> In comp.os.linux.misc, c186282  <c186282@nnada.net> 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 :-)

[toc] | [prev] | [next] | [standalone]

#88842

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.

[toc] | [prev] | [next] | [standalone]

#88844

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.

[toc] | [prev] | [next] | [standalone]

#88845

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.

[toc] | [prev] | [next] | [standalone]

#88853

On 7/11/26 23:00, rbowman wrote:
> 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.

   I've used subprocess quite a bit. It is theoretically
   'more capable' but can be far more complicated than
   needed. 'os.system()' is my pref wherever possible.
   If I need output from some call then subprocess will
   deliver that. In this particular case I just had the
   util dump to a temporary file. Just a few lines to
   open/read/clean the contents. No real advantage in
   using subprocess, so I didn't. KISS

[toc] | [prev] | [next] | [standalone]

#88846

c186282 <c186282@nnada.net> 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.

[toc] | [prev] | [next] | [standalone]

#88854

On 7/11/26 23:36, Rich wrote:
> c186282 <c186282@nnada.net> 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.

   Some were late to class that day  :-)

[toc] | [prev] | [next] | [standalone]

#88856

On 13/07/2026 00:25, c186282 wrote:
> On 7/11/26 23:36, Rich wrote:
>> c186282 <c186282@nnada.net> 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.
> 
>    Some were late to class that day  :-)
> 
> 
More relevantly,
- no one knows all of Unix/Linux
- some peoples experience goes very deep is some areas
- conversely those areas having been been completely irrelevant and 
never explored is someone else's life experience.

For example, I never had any need whatsoever to type 'emacs' on a 
command line
Other peoples days (if their session was not still active) did that as 
the first thing in the morning.

It being some primitive approximation to a multi tasking windows session.


> 
> 

-- 
"First, find out who are the people you can not criticise. They are your 
oppressors."
      - George Orwell

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web