From: Darren Hart <dvhart@linux.intel.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: Poky <poky@lists.pokylinux.org>, Chris Larson <clarson@kergoth.com>
Subject: Re: Useless syslogd
Date: Mon, 14 Feb 2011 09:04:12 -0800 [thread overview]
Message-ID: <4D59608C.4090203@linux.intel.com> (raw)
In-Reply-To: <4D55B94E.9070700@mlbassoc.com>
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
next prev parent reply other threads:[~2011-02-14 17:04 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 [this message]
2011-02-14 17:19 ` Gary Thomas
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=4D59608C.4090203@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=clarson@kergoth.com \
--cc=gary@mlbassoc.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.