Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Wed, Feb 19, 2014 at 2:50 AM, J. Roeleveld <joost@××××××××.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 <joost@××××××××.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