[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: End of hypocrisy ?



On Wed, Aug 6, 2014 at 5:54 AM, Slavko <linux@slavino.sk> wrote:
> Dňa Tue, 5 Aug 2014 16:33:23 -0400 Tom H <tomh0665@gmail.com> napísal:
>> On Tue, Aug 5, 2014 at 9:50 AM, Slavko <linux@slavino.sk> wrote:
>>> Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H <tomh0665@gmail.com>
>>> napísal:


>>>> If tomh-init is faster than htom-init, whether there's just ssh
>>>> running or 100 daemons running, I want to use tomh-init.
>>>>
>>>> I can understand that there are people who don't want to adopt
>>>> systemd simply because it boots faster because they dislike some
>>>> other aspect(s) of systemd, but attacking systemd because it boots
>>>> faster is silly.
>>>
>>> I know, that you are not responding to me, but i have one note:
>>>
>>> The boot speed is often used as argument for the systemd. But no all
>>> users are interested on boot time, then there are reaction as this
>>> (and as my). IMO, there aren't a lot information about other
>>> aspects of systemd and then people (include me) don't know about
>>> them.
>>>
>>> Until will be boot time again and again used as argument, then here
>>> will be responses as these.
>>>
>>> To be precise, i often read about these things: monolitic, binary
>>> files and boot speed. I don't like first two and i am not
>>> interested in latest.
>>
>> I thought that I'd answered you.
>>
>> I'm objecting to this line of reasoning: I'm not interested in boot
>> speed therefore I'm not interested in systemd.
>>
>> Since you're not interested in boot speed, you shouldn't care that
>> boot's faster with systemd! You don't have to dislike everything that
>> systemd claims that it provides.
>>
>> But if you want to say "boot speed isn't enough of an argument for me
>> to like/use systemd", fine.
>
> Yes, that is what i mean, thanks for help - writing my thinks in
> English is sometime terrible for me.

You're welcome. I'm glad that we cleared this up.


> Yes, you have rsyslog for storing logs in text files. Now you have two
> deamons for one thing. Nice, but where is the advantage?
>
> I understand that sometime there is time to change, e.g. from text to
> binary files, it is OK. But to i (and perhaps others too) can accept
> this change, it must give something, what is useful for me.

Imagine if the systemd maintainers proposed to replace rsyslog with
journald. I'd unsubscribe for a month or two in order to let the
outrage die down. :)

At my $day_job, as part of our future RHEL 7 rollout, we're looking
into using journald for local logs and configuring rsyslog to send our
logs to a dedicated syslog server without storing any of the usual
"/var/log/" files locally.

This is from an email by Lennart:

/var/log/messages is *very* badly designed:

  The timestamps do not contain a year
  The timestamps do not contain a timezone
  The timestamps are accurate to the second only
  PID information is optional, not implied
  PID information is fakeable, because user supplied
  The file "tag" part is completely optional, free-form, and fakeable
by unpriveed clients
  The files do not carry any information about the log priority
  The files do not carry any information about who is logging
(service, process name, argv, binary path..)
  The files do not carry any information about the credentials of who
is logging (uid, gid, selinux context, audit, ...)

And so on and so on.

It's so bad, that rsyslog upstream even suggests not to use these files
anymore, but write them in a more modern formatting that leaves a bit
more information in (such as iso timestamps). But you know what? If you
do that than all your compatibility is gone too.

The interesting things is that "journalctl" is *better* at generating
the same text stream that is normally contained in /var/log/messages
than /var/log/messages itself is. "journalctl" can stuff more
information into it then /var/log/messages. And how does that happen?
Because we have more data around. We can agument the ouput with colors
(indicating priorities), we can add additional informational separator
lines (indicating reboots), we can add add in fields that aren't there
(such as the tag from the comm field, or the PID). We can timezone
correct the timestamps (because we have UTC times). And we can filter by
any of the fields, securely.

So, yeah, /var/log/messages sucks, and journalctl is better at
generating a compatible output that that file ever was in itself.

I didn't save the URL :(

And another:

> So maybe we (Fedora) should go with XML instead of binary or some
> dedicated RDMBS for storing system logs? I'm not against binary log
> format but try to understand why it's superior to text and also why
> something more sophisticated isn't used if we really need this
> additional meta data that could not be included in plain text?

XML and text files are not sanely indexable.

Real database are large packages that we cannot pull into minimal systems.

Beyond that, and that's most important: the specific requirements are
different from what those systems provide. We want something minimal,
C-based, that can work without any service around, that can be mmapped
by multiple processes at the same time. Something that indexes
implicitly by all keys without any pre-defined schema. Something that
is primarily append-only (for robustness reasons). Something that is
indexed by time, and interleavable. Something that can store binary
blobs, that can optionally compress larger blobs. Something that can be
rotated. Something that supports Unix access controls
natively. Something that provides us with the right complexity
guarantees. And more...

I didn't save the URL either. Sorry.


> Then what are advantages of the systemd? I see only disadvantages...

I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug
thread. I can dig them up and post them if you're interested.

Personally, I don't care. It's what I have to use so I've learned
about it and I'm using it. End of story.


Reply to: