From: Gary Thomas <gary@mlbassoc.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Poky <poky@lists.pokylinux.org>, Chris Larson <clarson@kergoth.com>
Subject: Re: Useless syslogd
Date: Mon, 14 Feb 2011 10:19:55 -0700 [thread overview]
Message-ID: <4D59643B.3010408@mlbassoc.com> (raw)
In-Reply-To: <4D59608C.4090203@linux.intel.com>
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
------------------------------------------------------------
prev parent reply other threads:[~2011-02-14 17:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-11 20:47 Useless syslogd Gary Thomas
2011-02-11 21:50 ` Tom Zanussi
2011-02-11 22:26 ` Gary Thomas
2011-02-11 22:27 ` Chris Larson
2011-02-11 22:33 ` Gary Thomas
2011-02-14 17:04 ` Darren Hart
2011-02-14 17:19 ` Gary Thomas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D59643B.3010408@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=clarson@kergoth.com \
--cc=dvhart@linux.intel.com \
--cc=poky@lists.pokylinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.