[nos-bbs] trace files
Michael Fox - N6MEF
n6mef at mefox.org
Wed Sep 22 16:00:06 EDT 2010
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.
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
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.
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
Well -- it certainly changes the timeliness and approach to trouble
> 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].
Good luck with your JNOS
More information about the nos-bbs