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. >> But, if that is the only method to get parseable text from journalctl, >> then that is less then useless. > > I only put that option as tongue-in-cheek, since someone complained > about not being able to "cat" the logs. Many more options are > available. 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? >> 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. > > Everybody agrees with that; that's why the journal supports a lot of > formatting options. From [2]: > <SNIPPED man-page> > > So you can have the default; journalctl -b | head: > > -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18 > 08:28:44 CST. -- > Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is > using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit > 198.0M). > Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is > using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit > 198.0M). <SNIPPED log examples> > > See if you can easily do that with rsyslog or syslog-ng. Not easily, but I do not see the point, beyond as a nice gimmick. Same question applies, can I disable these code-paths during compile-time? I have log-parsing scripts that check for unexpected log-entries which expect syslog-standard logs. I do not see the need to have to spend time to change working code to be able to handle different formats. Additionally, the use of "tail -f" and "grep" allows me to check the logs real-time for debugging purposes. Having to use a seperate tool that converts some proprietary binary format to human readable/scriptable single-line logs makes no sense. It all sounds too much like the MS Windows Event-viewer to me. Too many events with no usefull logging information (And I am referring to OS-level messages as to why default services are not starting) -- Joost