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?
On Jun 14, 2013 8:34 PM, "Matthew Miller" mattdm@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
On Wed, Jun 19, 2013 at 07:08:07PM -0700, Garrett Holmstrom wrote:
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.
As I understand it, the FESCO descision was that rsyslog will stay in the default right now, and then the systemd maintainers decided to start logging to disk _as well_, with the rationale that they can make that as a "local" decision to the package, and then basically everyone just shrugged. Was there more that I missed?
The key thing is that the extra disk isn't a big deal locally but I feel icky doing double-logging-to-disk in cloud images. So I don't feel like *we* can just shrug.
In fact, I'm also kind of thinking we should be more strict with RuntimeMaxUse to keep memory footprint down too.
cloud@lists.stg.fedoraproject.org