On Wed, Feb 19, 2014 at 2:50 AM, J. Roeleveld <jo...@antarean.org> wrote: > On Tue, February 18, 2014 15:37, Canek Peláez Valdés wrote: >> On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld <jo...@antarean.org> wrote: >>> As I do not have systemd installed on any machine, I can't check the >>> man-pages. >> >> They are online [1]. > > Useful, but not necessary for this discussion.
It was just a pointer. > I see this option as a easter-egg without any real value. How many of > these useless code-paths are implemented? > Can these be disabled at compile time? That's neither here nor there; you said "I would expect an export option providing the same detail level as I currently find in /var/log/messages. A timestamp is a minimum required for logging system output."; I proved to you that the journal shows timestamps and much more, if so desired. [ snip ] >> See if you can easily do that with rsyslog or syslog-ng. > > Not easily, That's (one of) the advantage(s) that the journal brings. BTW, I'm not trying to convince anyone to use the journal (nor systemd); I'm just pointing out about features. > 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 > Same question applies, can I disable these code-paths during compile-time? No you can't; if you wanted the journal to work exactly as rsyslog (or syslog-ng), then there is no reason to use the journal. Its raison d'être is the new features it brings. If you don't want those features, don't use the journal. > I have log-parsing scripts that check for unexpected log-entries which > expect syslog-standard logs. I used, too. The journal makes most of then unnecessary, and if I want to, it can provide formatting of the logs in the same way that rsyslog (or syslog-ng) does. > I do not see the need to have to spend time to change working code to be > able to handle different formats. Well, I prefer it when someone does the work for me. > 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]. > Having to use a seperate tool that converts some proprietary binary format > to human readable/scriptable single-line logs makes no sense. Its not proprietary; the source code is available, you can write your own parser if you want. The binary format is to be able to do O(log n) searches, that's it. It's a performance optimization. > It all sounds too much like the MS Windows Event-viewer to me. Never used it. > Too many events with no usefull logging information (And I am referring to > OS-level messages as to why default services are not starting) 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. If you *want* to, everything is online. Regards. [1] http://www.freedesktop.org/software/systemd/man/journalctl.html [2] http://www.freedesktop.org/software/systemd/man/systemctl.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
