Most large organizations have policies for data retention, which may include operating system log files. These policies usually specify both the minimum time data must be retained and a time after which it must be deleted. Currently, systemd only uses a disk-space-free heuristic for log rotation. The syslog-derived log systems plus logrotate give an easy and effective way of implementing data retention policies. In order to be used in these environments, systemd's journal needs the same.
SOme system even require that logs are never rotated automatically and that the machine must crash if logs can't be written, so systemd must allow for boundless configuration and just let the machine crash when disk space is not available anymore.
I am not strictly opposed to having time-based in journald, but I disagree with the statement that the journal *needs* to support that. We could tell users with similar requirements to disable journal storage and defer to rsyslog for data retention.
(In reply to comment #2) > I am not strictly opposed to having time-based in journald, but I disagree > with the statement that the journal *needs* to support that. We could tell > users with similar requirements to disable journal storage and defer to > rsyslog for data retention. "Needs" is if we want to not ship rsyslog by default anymore. "Strongly want as an important and useful feature which will help people and help both Fedora and systemd" is the general statement. :)
There is absolutely no need for that period administrator can still install either rsyslog or syslog-ng if they either need or want this feature...
(In reply to comment #4) > There is absolutely no need for that period administrator can still install > either rsyslog or syslog-ng if they either need or want this feature... That doesn't help the mandatory cases. But in general (and I think more importantly), it also means that users who arguably _most benefit_ from the new features systemd's journal brings (e.g., reliable and better metadata) don't actually get them. Falling back to "bah, they should use the old system" doesn't seem satisfactory to me.
(In reply to comment #4) > There is absolutely no need for that period administrator can still install > either rsyslog or syslog-ng if they either need or want this feature... Can the journal be disabled in such a case? In some cases law or company policy forbids to keep certain log files after a certain period of time. If such log data would end up in the journal, one could run into problems.
You can disable the storage of journal data using "Storage=none" in /etc/systemd/journald.conf.
(In reply to comment #7) > You can disable the storage of journal data using "Storage=none" in > /etc/systemd/journald.conf. What exactly does this option do? Does this only affect what get's persistently stored in /var/log or also what is stored in /run?
Both /var/log and /run/log. See the manpage for other possible values of the option: http://0pointer.de/public/systemd-man/journald.conf.html
Implemented in git. Will upload to F18 soon too.
systemd-195-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-195-1.fc18
Package systemd-195-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-1.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-1.fc18 then log in and leave karma (feedback).
Package systemd-195-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18 then log in and leave karma (feedback).
systemd-195-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.