Useless syslogd

Useless syslogd

[Gary Thomas]

... at least out of the box.

It seems that syslog is configured to store its messages in
a buffer (memory only?) by default:

$ cat meta/recipes-core/busybox/files/syslog.conf
DESTINATION="buffer"            # log destinations (buffer file remote)
   ...

This doesn't seem very useful to me.  I know I can override this
in my platform recipes, but I was just wondering what's the
rationale?  Would it not make more sense to chose DESTINATION="file"?
Otherwise, where do the messages go?  How can I see them?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Useless syslogd

[Tom Zanussi]

On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
> ... at least out of the box.
> 
> It seems that syslog is configured to store its messages in
> a buffer (memory only?) by default:
> 
> $ cat meta/recipes-core/busybox/files/syslog.conf
> DESTINATION="buffer"            # log destinations (buffer file remote)
>    ...
> 
> This doesn't seem very useful to me.  I know I can override this
> in my platform recipes, but I was just wondering what's the
> rationale?  Would it not make more sense to chose DESTINATION="file"?
> Otherwise, where do the messages go?  How can I see them?
> 

I think 'logread' is hooked up to read from the buffer, but it seems to
be broken at the moment...

Tom


 

Re: Useless syslogd

[Gary Thomas]

On 02/11/2011 02:50 PM, Tom Zanussi wrote:
> On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
>> ... at least out of the box.
>>
>> It seems that syslog is configured to store its messages in
>> a buffer (memory only?) by default:
>>
>> $ cat meta/recipes-core/busybox/files/syslog.conf
>> DESTINATION="buffer"            # log destinations (buffer file remote)
>>     ...
>>
>> This doesn't seem very useful to me.  I know I can override this
>> in my platform recipes, but I was just wondering what's the
>> rationale?  Would it not make more sense to chose DESTINATION="file"?
>> Otherwise, where do the messages go?  How can I see them?
>>
>
> I think 'logread' is hooked up to read from the buffer, but it seems to
> be broken at the moment...

Thanks for pointing this out.  It does seem to work (minimal
test), but I still prefer a file, especially since the buffer
mode seems to use a circular buffer that could get overwritten.

At least I have an easy way to define my own config file.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Useless syslogd

[Chris Larson]

On Fri, Feb 11, 2011 at 2:50 PM, Tom Zanussi <tom.zanussi@intel.com> wrote:
> On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
>> ... at least out of the box.
>>
>> It seems that syslog is configured to store its messages in
>> a buffer (memory only?) by default:
>>
>> $ cat meta/recipes-core/busybox/files/syslog.conf
>> DESTINATION="buffer"            # log destinations (buffer file remote)
>>    ...
>>
>> This doesn't seem very useful to me.  I know I can override this
>> in my platform recipes, but I was just wondering what's the
>> rationale?  Would it not make more sense to chose DESTINATION="file"?
>> Otherwise, where do the messages go?  How can I see them?
>>
>
> I think 'logread' is hooked up to read from the buffer, but it seems to
> be broken at the moment...

logread is indeed the way to access the circular buffer, though it
does seem like operating against a file would be more consistent -- I
think the original logic was that most of the targeted devices didn't
have a writable area to put the logs, other than flash, if that, but
using tmpfs seems just as good a solution and the logs can be read in
a more traditional fashion..
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Useless syslogd

[Gary Thomas]

On 02/11/2011 03:27 PM, Chris Larson wrote:
> On Fri, Feb 11, 2011 at 2:50 PM, Tom Zanussi<tom.zanussi@intel.com>  wrote:
>> On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
>>> ... at least out of the box.
>>>
>>> It seems that syslog is configured to store its messages in
>>> a buffer (memory only?) by default:
>>>
>>> $ cat meta/recipes-core/busybox/files/syslog.conf
>>> DESTINATION="buffer"            # log destinations (buffer file remote)
>>>     ...
>>>
>>> This doesn't seem very useful to me.  I know I can override this
>>> in my platform recipes, but I was just wondering what's the
>>> rationale?  Would it not make more sense to chose DESTINATION="file"?
>>> Otherwise, where do the messages go?  How can I see them?
>>>
>>
>> I think 'logread' is hooked up to read from the buffer, but it seems to
>> be broken at the moment...
>
> logread is indeed the way to access the circular buffer, though it
> does seem like operating against a file would be more consistent -- I
> think the original logic was that most of the targeted devices didn't
> have a writable area to put the logs, other than flash, if that, but
> using tmpfs seems just as good a solution and the logs can be read in
> a more traditional fashion..

Indeed. I hacked it before(*) so that /var/log could be ramdisk
and then rotate the logs to FLASH periodically.  Sadly, this
isn't supported out of the box (at least busybox's logrotate
insists on keeping the rotated files in /var/log), but I think
it's the best of both worlds.

(*) using an ad-hoc logrotate that could have the rotated files
end up in a directory other than /var/log

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Useless syslogd

[Darren Hart]

On 02/11/2011 02:33 PM, Gary Thomas wrote:
> On 02/11/2011 03:27 PM, Chris Larson wrote:
>> On Fri, Feb 11, 2011 at 2:50 PM, Tom Zanussi<tom.zanussi@intel.com>
>> wrote:
>>> On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
>>>> ... at least out of the box.
>>>>
>>>> It seems that syslog is configured to store its messages in
>>>> a buffer (memory only?) by default:
>>>>
>>>> $ cat meta/recipes-core/busybox/files/syslog.conf
>>>> DESTINATION="buffer" # log destinations (buffer file remote)
>>>> ...
>>>>
>>>> This doesn't seem very useful to me. I know I can override this
>>>> in my platform recipes, but I was just wondering what's the
>>>> rationale? Would it not make more sense to chose DESTINATION="file"?
>>>> Otherwise, where do the messages go? How can I see them?
>>>>
>>>
>>> I think 'logread' is hooked up to read from the buffer, but it seems to
>>> be broken at the moment...
>>
>> logread is indeed the way to access the circular buffer, though it
>> does seem like operating against a file would be more consistent -- I
>> think the original logic was that most of the targeted devices didn't
>> have a writable area to put the logs, other than flash, if that, but
>> using tmpfs seems just as good a solution and the logs can be read in
>> a more traditional fashion..
>
> Indeed. I hacked it before(*) so that /var/log could be ramdisk
> and then rotate the logs to FLASH periodically. Sadly, this
> isn't supported out of the box (at least busybox's logrotate
> insists on keeping the rotated files in /var/log), but I think
> it's the best of both worlds.
>
> (*) using an ad-hoc logrotate that could have the rotated files
> end up in a directory other than /var/log
>

I think this is a good idea, but I don't know that anyone will have the 
time to jump on it right now. May I suggest you open a bug / feature 
enhancement so we don't lose track of this?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Useless syslogd

[Gary Thomas]

On 02/14/2011 10:04 AM, Darren Hart wrote:
> On 02/11/2011 02:33 PM, Gary Thomas wrote:
>> On 02/11/2011 03:27 PM, Chris Larson wrote:
>>> On Fri, Feb 11, 2011 at 2:50 PM, Tom Zanussi<tom.zanussi@intel.com>
>>> wrote:
>>>> On Fri, 2011-02-11 at 12:47 -0800, Gary Thomas wrote:
>>>>> ... at least out of the box.
>>>>>
>>>>> It seems that syslog is configured to store its messages in
>>>>> a buffer (memory only?) by default:
>>>>>
>>>>> $ cat meta/recipes-core/busybox/files/syslog.conf
>>>>> DESTINATION="buffer" # log destinations (buffer file remote)
>>>>> ...
>>>>>
>>>>> This doesn't seem very useful to me. I know I can override this
>>>>> in my platform recipes, but I was just wondering what's the
>>>>> rationale? Would it not make more sense to chose DESTINATION="file"?
>>>>> Otherwise, where do the messages go? How can I see them?
>>>>>
>>>>
>>>> I think 'logread' is hooked up to read from the buffer, but it seems to
>>>> be broken at the moment...
>>>
>>> logread is indeed the way to access the circular buffer, though it
>>> does seem like operating against a file would be more consistent -- I
>>> think the original logic was that most of the targeted devices didn't
>>> have a writable area to put the logs, other than flash, if that, but
>>> using tmpfs seems just as good a solution and the logs can be read in
>>> a more traditional fashion..
>>
>> Indeed. I hacked it before(*) so that /var/log could be ramdisk
>> and then rotate the logs to FLASH periodically. Sadly, this
>> isn't supported out of the box (at least busybox's logrotate
>> insists on keeping the rotated files in /var/log), but I think
>> it's the best of both worlds.
>>
>> (*) using an ad-hoc logrotate that could have the rotated files
>> end up in a directory other than /var/log
>>
>
> I think this is a good idea, but I don't know that anyone will have the time to jump on it right now. May I suggest you open a bug / feature enhancement so we don't lose track of
> this?

Done as two separate bugs
   Bug 717 - Improve syslog configurability
   Bug 718 - Allow logrotate to use a different file system from the original logs

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------