20.02.2014 09:24, Canek Peláez Valdés пишет:
[ snip ]
but I do not see the point, beyond as a nice gimmick.
Well, I *do* see a point. Many points, actually. You want the logs for
SSH, from February 12 to February 15? Done:
journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service
No grep. No cat. No hunting logrotated logs (the journal will rotate
automatically its logs, and will search on all logs available). You
can have second-precision intervals.
>
Also, the binary format that the journal uses is indexed (hence the
binary part); therefore, the search is O(log n), no O(n). With a log
with a million entries, that's about 20 steps.
Perhaps it's just a gimmick to you. For me is a really usefull
Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n))
if really needed is easily achieved with databases.
Not using cat and grep is not something one'd boast; rather, again, a
waste of resources to recreate already existing tools.
BTW, I wonder if anyone does really have logs with millions of lines in
one single file, not split into files by date, service etc, so that the
whole O(n) issue is moot.
Well, maybe it'd be nice to have a collection of log management tools
all-in-one but beyond that I don't see any advantages of systemd-journald.
Its raison d'être is the new features it brings.
I didn't notice any new features. It's not features that are new, but
just a new implementation of old features in a more obtrusive way IMO.
Additionally, the use of "tail -f" and "grep" allows me to check the logs
real-time for debugging purposes.
journalctl -f
Checks the logs in real time. Again, [1].
Again, a brand new Wheel(c)
systemctl status apache2.service
(see [2]) will print the status of the Apache web server, and also the
last lines from the logs. You can control how many lines. You can
check also with the journal, as I showed up.
I believe it would be a 5-minutes job to add the capability of printing
last N log entries for a service to `rc-service status`. Using cat, grep
and the like. Not reinventing wheels. Not spending super-talented
super-highly paid developers' time on doing tasks one had done about 30
years ago. I believe, not having this option is due to its simple
uselessness.
This way I really wonder if at some point the super talented systemd
programmers decide that all shell tools are obsolete and every program
should know how to index or filter or tail its output in its own,
though, open, binary format. I can't get rid of the idea that systemd
uses the MS Windows approach whatever you say about its open source.
--
Regards,
Yuri K. Shatroff
