SAM mode overflows the LOG? [fixed in v1.602]

N1NKMN1NKM
edited May 3 in Problems Now Fixed

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

  • jksjks

    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.

  • N1NKMN1NKM

    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! :)

  • jksjks
    edited April 30

    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 for make log (control-C to stop). To see fewer messages you're supposed to be able to type msl (alias for make 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.

  • WA2ZKDWA2ZKD

    grep LEAVING upper case

  • jksjks

    Yes. Instead of grep I was thinking of the gr alias which does a grep -i a case-insensitive search (post edited to use gr).

  • N1NKMN1NKM

    I have some Linux knowledge. I switched to Mint a few years ago, abandoning Windows almost entirely. I'll have to check this out. :)

  • N1NKMN1NKM

    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.

  • jksjks

    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.

  • N1NKMN1NKM

    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? :)

  • jksjks

    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:

    Thu Aug 24 21:27:04 00:00:49.134 0... 0      TLIMIT exempt local connection from 192.168.1.52
Thu Aug 24 21:27:05 00:00:49.241 0... 0      WF interp=3(drop) cic_comp=1
Thu Aug 24 21:27:05 00:00:49.242 0... 0      WF window_func=2
Thu Aug 24 21:27:10 00:00:54.223 0... 0    L 15000.00 kHz usb z10 "ZL/KF6VO" 192.168.1.52 Tauranga, New Zealand (ARRIVED)
Thu Aug 24 21:27:47 00:01:32.158 0... 0    L 15000.00 kHz usb z10 "ZL/KF6VO" 192.168.1.52 Tauranga, New Zealand (LEAVING after 0:00:44)

    /var/log/user.log:

    Aug 24 21:27:10 ai64 kiwid: 00:00:54.233 0... 0  15000.00 kHz usb z10 "ZL/KF6VO" 192.168.1.52 Tauranga, New Zealand (ARRIVED)
Aug 24 21:27:47 ai64 kiwid: 00:01:32.158 0... 0  15000.00 kHz usb z10 "ZL/KF6VO" 192.168.1.52 Tauranga, New Zealand (LEAVING after 0:00:44)


  • N1NKMN1NKM

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

  • jksjks
    edited August 26

    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.

  • N1NKMN1NKM

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

  • jksjks

    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 called user.log.[234].gz (gzipped).

Sign In or Register to comment.