On 02/28/2014 12:54 AM, Chris Murphy wrote:
On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson <l...@homer.se> wrote:
On 02/26/14 19:23, lee wrote:
What is the purpose of this log duplication? When systemd has its own
logs, it doesn´t seem necessary to duplicate them by sending their
contents to syslogd.
One could also ask why systemd duplicates the logging formerly only done by
syslogd.
This has been answered many times already, it's an old argument.
That was not my point of argument.
For me looking through my ASCII-based text-logs created by syslogd is far
faster than using journalctl. Things that takes over 25 minutes with
journalctl, only takes 66 seconds grepping the syslogd logs. (see bug 1047719,
that no-one seems to care about)
Why are the logs so large? Each log file I have is either 8MB, 16MB, or maximum
24MB. So somehow yours are getting very large before they are turned over. Also
do you normally search all logs for all time? Or are you searching in the most
recent boot? You can use journalctl -b -1 to search the last boot, -2 the one
before that. It can be done using --since with a date to encompass multiple
boots yet not all boots. There is also -u to filter by unit. If you have
journalctl do some filtering in advance then not so much stuff is dumped into
grep to filter.
Why the journal is 4GB? Have no idea, perhaps you could enlighten me?
The syslogd created text files are only using about 700MB of space for
the same duration. The problem is not the size of the text files, the
problem is that systemd/journalctl is extremely sluggish when the
journal is big. If it takes 20-25 minutes to get the same information
from journalctl, when it takes about 1 minute going through all syslogd
created text-files for the same duration, then something is utterly
wrong with how the journal works, and if it (the journal) is supposed to
replace the syslogd generated text files, it has to be at least equally
fast to be usable.
Also note that this sluggishness creates problem for the 'systemctl
status' command, which is a really bad thing.
Using -b, --since, etc. is not the point, the point is the sluggishness
shown when the journal is big.
ASCII-based logs can be read by anybody using any editor. To read the journal
you need journalctl, or similar program, as the journal is binary and not
readily readable.
It's fine to want plain logs but that is a subset of the amount of information
the journal can only retain with binary including checksumming so the logs can
be verified, and universal time/date stamping that causes journalctl to report
the even in local time even if the server is not local, the list of things that
can be done are unlimited. So the superset log is a necessity in any case and
if the plain text rsyslog is meeting your needs then why would you bother with
journalctl at all?
That is all fine and dandy, but does not change the fact that a text
file can be read by anyone. The journal needs programs of some sort to
be read.
Another reason is that there still exist programs/daemons/etc. that rely on the
logs in /var/log.
If you do not like syslogd, well F20 does not ship it anymore…
I think the repo has both rsyslog and syslog-ng.
That does not change the fact that the F20 install has dameons etc. that
actually relies on a present MTA and/or the syslog daemon.
Lars
--
Lars E. Pettersson <l...@homer.se>
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
