SAM mode overflows the LOG? [fixed in v1.602]
Hi, I'm wondering if I'm overlooking a setting? Is there a way to stop these oft-repeated entries from pushing out other, more useful data? :)
I usually use the SAM mode when listening to SW station, but then this happens... and anything else in the log gets overwritten. :(
Fri Apr 28 16:21:53 3d:10:11:33.323 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:21:56 3d:10:11:36.560 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:21:56 3d:10:11:36.660 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:21:59 3d:10:11:39.584 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:21:59 3d:10:11:39.685 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:03 3d:10:16:43.893 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:05 3d:10:16:45.914 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:08 3d:10:16:48.347 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:18 3d:10:16:58.458 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:18 3d:10:16:58.559 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:52 3d:10:17:32.229 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:52 3d:10:17:32.338 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:58 3d:10:17:38.912 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:27:58 3d:10:17:39.012 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:00 3d:10:17:40.831 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:00 3d:10:17:40.931 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:04 3d:10:17:44.268 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:04 3d:10:17:44.369 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:06 3d:10:17:46.992 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:06 3d:10:17:47.103 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:11 3d:10:17:51.244 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:11 3d:10:17:51.343 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:13 3d:10:17:53.264 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:13 3d:10:17:53.363 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:15 3d:10:17:55.699 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0 Fri Apr 28 16:28:15 3d:10:17:55.796 0.. 0 SAM DC_block=1 fade_leveler=1 chan_null=0
I have V1.601 installed.
Thanks!
Comments
I can comment out that message in the next release. It only happens when you push the SAx mode button.
Note that there are actually two logs. The in-memory log, which is what you see in the admin log tab. And the Linux system log. Only in-memory log messages prefaced with a capital "L" appear in the system log. So even though those messages are annoying as they are obscuring the in-memory log they are not also filling up the system log recorded on the filesystem.
OK, how do I access the other log? I just want to see how often a few of my friends are logging in and listening. :)
Thanks! :)
The answer to that question depends on how much Linux knowledge you have.
The Linux files
/var/log/user.log
(and the older compressed logs/var/log/user.log.N.gz
) are where the Kiwi messages are logged.There are a couple of Makefile targets to make this a bit easier. Bring up the admin page, console tab. Connect and type
ml
which is a short alias formake log
(control-C to stop). To see fewer messages you're supposed to be able to typemsl
(alias formake slog
"short log") . BUT I see this is broken at the moment. So I'll fix in the next release.You'll probably want to search the output from that rather than seeing the whole thing, e.g.
ml | gr leaving
to search for when users disconnected.
grep LEAVING upper case
Yes. Instead of
grep
I was thinking of thegr
alias which does agrep -i
a case-insensitive search (post edited to usegr
).I have some Linux knowledge. I switched to Mint a few years ago, abandoning Windows almost entirely. I'll have to check this out. :)
It took me a while to get a ROUND TUIT, but I finally just tinkered with this. Interesting. It takes several seconds to return any text. Is it searching the ENTIRE LOG, or only searching the truncated version that is visible on the Admin page? Ideally, I'd like to have it save ONLY the user connect and disconnect session data to a separate file. Said file shouldn't be very large, as I only gave the address to a handful of people, and it is not on the Kiwi net.
Linux commands that are invoked out of the Makefile are super slow because the Makefile has to evaluate hundreds (if not thousands) of source code dependencies before it does anything, including just running simple commands. So this has nothing to do with the speed of searching the log files.
I've been meaning to fix/improve this, but it's way, way down on the priority list. Alternatively there could be a shell alias to do this. Or once you figure out the sequence of shell commands you need to do this you could put them in a script file.
Oh, I'm not anywhere near THAT proficient in Linux. ;) I appreciate that this functionality is available at all. :)
But I still wonder... is it searching the entire log, or only the truncated version that shows on the Admin page? :)
Sorry, I didn't answer your question completely: The commands in the Makefile, and any you come up with yourself, that search the /var/log/user.log file et al, will only see the messages in the Kiwi admin log tab that contain the "L" character. So in the example below you'd be able to search for the "ARRIVED" and "LEAVING" messages.
Admin log tab:
/var/log/user.log:
I'm still confused... the Admin log tab shows a truncated log. About half way down, it has a yellow line that says ----- xx Lines Not Shown -----
So when a Makefile command is used... is it searching the WHOLE log, or only searching the one with the "lines not shown"? (Meaning, it is NOT seeing a significant chunk.)
Thanks. :)
Yes, that's another small complication. The admin log tab has that split screen that only displays messages from server start time in the upper half, and the most recent at the bottom. Otherwise the scrolling window could become gigantic and your browser/device crawl to a halt.
But each and every message generated containing the "L", destined for the system log files (/var/log/user.*.log), and searched by those Makefile commands, are searchable. Despite the limited output of the admin log tab. So you should get all the "ARRIVED" and "LEAVING" messages when searching.
The admin log tab will lose all but those first and last non-L messages, but those tend to be debugging oriented and not as important.
OK, so what is the storage limit of the internal log file? Obviously, it, too, has a limit to prevent devouring space and crashing the unit. :)
Parallel story: Unbeknownst to me, for a couple days, I had a bad printer driver on my Linux PC. When it decided to act up, it took it only MINUTES to literally flood the 64 Gig hard drive (every free byte!) with a single log file, full of error messages! Eventually, someone on a Linux Forum helped me isolate the cause! (Boot Linux from CD, purge the massive .log file, reboot from HD and use it for a few minutes while it flooded, until cause was found and eliminated.)
Sure, and we've seen this problem occasionally.
There are a couple of mechanisms that try to limit the impact of large log files. First, you can see the amount of free filesystem space by using the
df .
alias. It should be very roughly 700MB - 1.7GB, depending.The Kiwi mechanism of not sending debug messages to the Linux system log should also help (the non-"L" messages).
The Linux log files themselves get rotated and compressed on some schedule. Hence why in
/var/log
there are files calleduser.log.[234].gz
(gzipped).