double logging -- should we turn one of these off?

Garrett Holmstrom gholms at fedoraproject.org
Thu Jun 20 02:08:07 UTC 2013


On Jun 14, 2013 8:34 PM, "Matthew Miller" <mattdm at fedoraproject.org> wrote:
>
> Sooooo. As of systemd 198-1, (March 7th), systemd enables persistent
logging
> of the journal by default -- that means, it's writing it to disk.
>
> I'm not really excited about logging every event twice in the cloud image.
> The journal will do handwavy magic to automatically keep from running out
of
> space, but until it hits its threshold, it _will_ be using up more disk.
>
> I posted a message to the main devel list last year sometime about what
> realistic requirements Fedora might have for making the systemd journal
the
> default logging option for the whole distro. (See
> https://lists.fedoraproject.org/pipermail/devel/2012-October/172682.html)
>
> Of the things I listed as critical, some very key ones like time-based
> rotation and "journal format documented" are done. Others are still
lacking,
> like a mechanism for separation of authpriv data, easy Fedora-centric
> disaster recovery documentation, and, simply, a lot of QA and testing.
>
> So, the question is: do we want to be part of the testing ground for this?
> There are some advantages, including of course less stuff in the image,
> and anyone wanting more complicated configuration can easily install
> rsyslog, and, given limited space, automatic free space management.
>
> Or, do we want to disable the persistent store, and rely on rsyslog?
>
> Or, do we want to just leave it?

I think it should default to the same thing every other spin defaults to
until FESCo decide to reverse their earlier decision on this issue.
Differing before that happens forces people to do all the work you
described, just for the benefit of a single spin that is among the easiest
to customize.

--
Garrett Holmstrom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20130619/4a1c8412/attachment-0001.html>


More information about the cloud mailing list