Re: questions/suggestion "RAM-only" log support in sysklogd?

Hi!

Guy, I would also be interested in such a feature.

Recently[1] I ported the log rotation code from BusyBox syslogd to
sysklogd. But the BusyBox syslogd also has a sort of ring buffer
implementation that can be "hooked into" using a separate tool,
logread, but it always logs to disk. However, I don't think it would
be too much problem to alter that behavior so that it only logs to
disk on signal.

Regards
 /Joachim

[1] - http://lists.infodrom.org/infodrom-sysklogd/2009/0008.html

On Mon, Jan 4, 2010 at 9:16 AM, Kjeld Flarup Christensen
<kjeld.flarup.christensen_at_ericsson.com> wrote:
>
> Hi Guy
>
> We have a patch, which puts a limit on the size of a log file.
>
> So if you write ex
>
> *.* /tmp/messages,10000
>
> Then you will get a log file of max 10M, and when 10M is reached the file is renamed to /tmp/messages~
>
> --------------------------- With Regards ------------------------
>  Kjeld Flarup (Christensen), Specialist, Software Architecture and Technology
>  Ericsson Danmark A/S, PDU MSA
>  Faelledvej 17, DK-7600 Struer, Phone +45 9786 9410, Mobile: +45 4029 4149 Fax +45 9785 4422
> -----------------------------------| A too small part of Ericsson |
>
>
>
>
>
> -----Original Message-----
> From: guy keren [mailto:guy.keren_at_kaminario.com]
> Sent: 22. december 2009 20:51
> To: infodrom-sysklogd_at_lists.infodrom.org
> Subject: questions/suggestion "RAM-only" log support in sysklogd?
>
>
> Hi,
>
> i was looking for a way to have some log messages (mostly debug messages, that i don't want to flood the disk normally) be stored in a cyclic memory buffer, instead of logged into a file - and only have this buffer dumped to disk upon demand (e.g. when there is a problem that requires debugging).
>
> i was wondering if a patch that adds such support is available anywhere, or if it will be considered for inclusion in sysklogd if provided.
>
> the motivation is being able to debug various problems with various software components the first time around - instead of having to re-produce them with higher debug levels - and yet without filling the disk with lots of junk and without causing too much disk activity when there's no need to look at these logs.
>
> note: we did consider simply placing certain log files in a RAM disk - but we then we'll need to handle the creation of this RAM disk, very often logrotate (to avoid having it fill up), etc - and it seems like a more awkward solution, and less robust in case of a sudden log-flood.
>
> thanks,
> --guy
>
>
> --
> To UNSUBSCRIBE, send an email to infodrom-sysklogd-request_at_lists.infodrom.org
> with a subject of "unsubscribe". Trouble? Contact listmaster_at_lists.infodrom.org
>
>
> --
> To UNSUBSCRIBE, send an email to infodrom-sysklogd-request_at_lists.infodrom.org
> with a subject of "unsubscribe". Trouble? Contact listmaster_at_lists.infodrom.org
>
>
Received on Mon Jan 04 2010 - 18:33:59 CET