[nos-bbs] trace files

[Michael Fox - N6MEF]

Thanks Skip.  

I was also just told by someone else that JNOS buffers before writing to the
file and that it will eventually write.  But how long/much does it buffer,
who knows?  And for what possible purpose?  I sent several pings, waited a
minute or so, and still no output.  That makes it impossible to diagnose a
problem that's occurring in real time.

You say below that Linux buffers the output.  But other linux logs don't
seem to be delayed like the JNOS log. Other logs I review show the events as
they happen.  How do you know it is Linux that's delaying the write and can
it be controlled (reduced to 0 or a small value)? 

I see no value in delaying the write to the file output - only problems.
Write it as you get it, just like syslog and other apps that produce log
files do.  It seems two improvements are needed to be able to diagnose a
problem that is occurring in real time:

1)  If a filename is specified, write each trace entry to the file without
delay.  Then I can run "tail -f" to view what's going on in real time.

2)  Also, write to the F9 window, even if a filename is specified.  This is
still helpful for more simple tasks.  For example, if I'm just trying to see
what's happening with a ping, I can switch between F10 and F9 and I don't
need to open another terminal window.

Michael
N6MEF


-----Original Message-----
From: George [ham] VerDuin [mailto:k8rra at ameritech.net] 
Sent: Wednesday, September 22, 2010 12:33 PM
To: n6mef at arrl.net; TAPR xNOS Mailing List
Subject: Re: [nos-bbs] trace files

Interesting Michael...

Michael Fox - N6MEF wrote:
>
>
> Also, when I specify a filename, the file is created, but has zero 
> size and nothing in it until I exit JNOS.  Really BAD.  So now I have 
> no trace output at all while JNOS is operating and, if it crashes, it 
> may not be able to write the trace output file.
>
Almost accurate.
Linux buffers output so while there is zero on HD there is non-zero in 
buffer waiting to fill up to the write threshold size.

Try a no-file trace command on the selected interface to cause JNOS to 
purge the buffer before changing the output path to the F9 tty.  There 
are more elegant solutions.

>  
>
> So, putting this together, tracking down a problem is virtually 
> impossible.
>
Well -- it certainly changes the timeliness and approach to trouble 
shooting.

>  
>
> It seems to me that:
>
> 1) JNOS should always write to the F9 session (unless strace is off, 
> in which case, it would write to the F10 session)
>
> 2) If a file is names, then JNOS would ALSO write to the file
>
> 3)  JNOS should write to the file as it is running.  NOT buffer 
> everything up until it terminates.
>
>  
>
> Is anyone else having this problem?  Is there a workaround?
>
Admittedly some issues solve best with immediate view of detail 
traffic.  For most of the issues I have maybe a year(+) of trace on the 
RF ports because I have the space to waste(?).  I have seen the thing 
you call out, but not found it any disadvantage.  Maybe even an 
advantage -- I typically filter the trace to aid in focus on only what 
I'm looking for.  Sometimes I edit the trace to add personal comments.   
Comments help me focus on the issue -- especially when setting the issue 
aside for a while then picking it up again later doesn't require me to 
re-discover fact from the previous review.

The way I work is not for everybody [for certain].
>
>  
>
> Michael
>
> N6MEF
>
Good luck with your JNOS
Skip