[arm-allstar] logging ideas.. was: update has an error
Tom Hayward
tom at tomh.us
Fri Jul 28 11:14:38 EST 2017
Doug,
You must have missed the beginning of the thread. We're not talking
about logging to an SD card, but rather creating a circular buffer of
stderr messages in memory. One way to do this is with a syslog
application, tmpfs (ramdisk), and log rotation. There is no need to
keep the data long term, just long enough so that the admin menu can
display whatever error was returned after one of its child apps
crashes.
Tom KD7LXL
On Fri, Jul 28, 2017 at 9:09 AM, Doug Crompton <wa3dsp at gmail.com> wrote:
> Please keep in mind that while logging is nice any logging that would
> survive a reboot has to write to the SD card. Currently all logging is done
> to RAM and not the SD card. Any method to log to SD should be something that
> could be turned on when necessary and the rest of the time turned off. Most
> would not need theses logs under normal circumstances. I am against anything
> that continually writes to the SD card, it is bad pratice.
>
> I run a hub that is 24/7 and I have implemented two methods to truncate
> logs. The scripts are attached if you want to see how I do it. Logs could
> also be rsync'ed to another system before truncating using a script like
> this.
>
> Also a user could install a USB stick and direct logging to it or use remote
> logging to another system.
>
> 73 Doug
> WA3DSP
> http://www.crompton.com/hamradio
>
>
>
> On Fri, Jul 28, 2017 at 11:34 AM, "David McGough via arm-allstar"
> <arm-allstar at hamvoip.org> wrote:
>>
>>
>> All the syslog utilities that I'm readily familiar with aren't as smart as
>> I'd like; these common tools will rotate all log entries into the waste
>> basket after a period of time and leave the administrator looking at empty
>> files....Ideally, the mechanism would always keep at least the amount of
>> log data specified by the low water mark setting...
>>
>> Anyhow, we'll figure out some strategy!
>>
>> 73, David KB4FXC
>>
>>
>>
>> On Fri, 28 Jul 2017, Tom Hayward wrote:
>>
>> > I definitely had something more simple in mind, like checking the
>> > return code of processes started by the menu.
>> >
>> > Most syslog utilities support log rotation on both size and time. I
>> > haven't looked at which one you use in Hamvoip, but it could probably
>> > be configured with the buffer capability you describe.
>> >
>> > Tom KD7LXL
>> >
>> > On Fri, Jul 28, 2017 at 7:52 AM, David McGough <kb4fxc at inttek.net>
>> > wrote:
>> > >
>> > > Hi Tom,
>> > >
>> > > I agree that in certain scenarios additional debugging info or logs
>> > > would
>> > > be very useful, as you suggest. As we all know, logs can also be a
>> > > problem, if allowed to grow without maintenance....I recently had a
>> > > low
>> > > memory issue due to logs on a busy RPi3 that had been up continuously
>> > > for
>> > > 2+ months.
>> > >
>> > > Ideally, application messages and those generated from Admin Menu
>> > > operations would get stored in a circular buffer, which could then be
>> > > queried from a menu option. There are already several tools which
>> > > could be
>> > > used, but, I'd like to have a little more flexibility---perhaps a
>> > > ring-buffer log that has a low and high water mark, but also includes
>> > > a
>> > > timestamp. So, the plan would be to weight the size of the buffer,
>> > > between
>> > > the water marks, based on the age of the log entries. The log would be
>> > > allowed to grow up to the high water mark in bursts, but then would
>> > > shrink
>> > > back to the low mark after a period of time.
>> > >
>> > > Do you (or anyone?) know of an ready-to-use tool that'll do this???
>> > >
>> > >
>> > > 73, David KB4FXC
>> > >
>> > >
>> > > On Thu, 27 Jul 2017, "Tom Hayward via arm-allstar" wrote:
>> > >
>> > >> On Thu, Jul 27, 2017 at 9:24 AM, "C B via arm-allstar"
>> > >> <arm-allstar at hamvoip.org> wrote:
>> > >> >
>> > >> > Thanks
>> > >> > would you consider having the error messages stay on the screen
>> > >> > until a OK button is pressed?
>> > >> > this may be helpful.
>> > >> > Chris
>> > >>
>> > >> That would be really helpful for any admin menu command that returned
>> > >> an error. The other day when I was affected by the buffer overflow
>> > >> bug
>> > >> for long hostnames, the observed behavior was that clicking
>> > >> simpleusb-tune-menu in the menu would immediately go back to the
>> > >> menu.
>> > >> I had to run the command from a bash shell before I could see that
>> > >> there was an error message and non-zero return code. Luckily I was
>> > >> the
>> > >> one working on it because the repeater owner I was working with isn't
>> > >> as familiar with Linux and probably wouldn't have thought to try
>> > >> that.
>> > >> The admin menu hides the complexity of bash, but in its current form
>> > >> it also hides all of the error detection and reporting functionality
>> > >> we have in bash.
>> > >>
>> > >> Tom KD7LXL
>> > >> _______________________________________________
>> > >>
>> > >> arm-allstar mailing list
>> > >> arm-allstar at hamvoip.org
>> > >> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>> > >>
>> > >> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>> > >>
>> > >
>> >
>>
>> _______________________________________________
>>
>> arm-allstar mailing list
>> arm-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>
>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>
>
More information about the arm-allstar
mailing list