6 ms·

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The d

by silon3 12y ago

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it.

Uberphallus 12y ago
Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.
- pgl 12y ago
  I found this to be the case as well. Especially on a busy system where there are a lot of events, when you're trying to find the cause of an issue and constantly opening and closing logs, the lag is definitely noticeable.
- rakoo 12y ago
  I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.
  - vidarh 12y ago
    Sounds like you're running into some bug. I've never run into any perceptible lag.
  - the_mitsuhiko 12y ago
    That sounds odd. Did you try to strace it and see what it actually does?
  - toupeira 12y ago
    Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
    - perlpimp 12y ago
      it is slow because log is read written in a block binary format but pager accepts byte granular fseek feature to go forward without loading everything into $PAGER's buffers.
    - rakoo 12y ago
      See ? People complaining before reading TFM. Thank you !
- mrweasel 12y ago
  I'm not currently using Linux, so I might be wrong, or misunderstanding what you're trying to do, but could you just have journald write to syslog? ForwardToSyslog=yes in /etc/systemd/journald.conf.
- the_mitsuhiko 12y ago
  To be honest: that's kinda to be expected if you run it on a slow machine. However you can configure it to be in-memory only and forward to syslog and you have it as it was before.
  - XorNot 12y ago
    I'm highly suspicious that syslog can actually be faster in such a situation. If you can't seek to the disk quickly, then it doesn't matter what you do - logging will be slow if you need to flush frequently.
the_mitsuhiko 12y ago
> The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it. To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken because you can read the unbroken stuff. Going by the bug tracker the journald approach is to make the reader work with broken files better.
- valarauca1 12y ago
  This is like saying. "I get shot going to work every day. But I bought a bullet proof vest, so life is okay." Iron bandages don't solve problems, they for a short time work around them. Except because nobody actually like writing systems level code, they stick- forever.
  - the_mitsuhiko 12y ago
    > "I get shot going to work every day. But I bought a bullet proof vest, so life is okay." You get corruption if the machine shuts down incorrectly. In binary or text files. In that case journald/syslogd act like a black box. Syslogd will give you whatever garbage it has in those text files, journald will give you the surviving records and will tell you which ones are unreadable. If you want to not get shot, shut down your machine properly. If you cannot shut down your machine properly because it crashed then you have data garbage if you want it or not. Drives work that way. I'm not sure what you are arguing for. Journald does not write broken records itself.
- XorNot 12y ago
  The binary logs are append only. The bug tracker entry says that they got "some corrupted logs" but not how. People get corrupted or truncated text logs all the time, they just ignore it because "oh the log ends midway through a line? eh". The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technical accuracy or discussion.
ape4 12y ago
I googled "libqrencode". Is it really QR code encoding?
- the_mitsuhiko 12y ago
  Yep. It's because when you kernel panic most people do not feel like typing stuff off a screen. If you have a QR code on your monitor however you can easily scan it and it contains all the info about what is wrong. That's a pretty good feature if you ask me.
  - ape4 12y ago
    That is a useful feature! The way it was written it sounded like QR codes were going into the logs.
  - uselessdguy 12y ago
    That's a Linux kernel feature, not a systemd feature. It's unrelated: http://www.linux.com/news/featured-blogs/200-libby-clark/773488-opw-intern-develops-qr-code-for-linux-kernel-oops-messages http://www.linux.com/news/featured-blogs/200-libby-clark/773... systemd has libqrencode integration, in order to, if I recall correctly, display a QR code when you generate FSS keys from journalctl.

by silon3 12y ago

Uberphallus 12y ago

Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

pgl 12y ago
I found this to be the case as well. Especially on a busy system where there are a lot of events, when you're trying to find the cause of an issue and constantly opening and closing logs, the lag is definitely noticeable.
rakoo 12y ago
I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.
- vidarh 12y ago
  Sounds like you're running into some bug. I've never run into any perceptible lag.
- the_mitsuhiko 12y ago
  That sounds odd. Did you try to strace it and see what it actually does?
- toupeira 12y ago
  Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
  - perlpimp 12y ago
    it is slow because log is read written in a block binary format but pager accepts byte granular fseek feature to go forward without loading everything into $PAGER's buffers.
  - rakoo 12y ago
    See ? People complaining before reading TFM. Thank you !
mrweasel 12y ago
I'm not currently using Linux, so I might be wrong, or misunderstanding what you're trying to do, but could you just have journald write to syslog? ForwardToSyslog=yes in /etc/systemd/journald.conf.
the_mitsuhiko 12y ago
To be honest: that's kinda to be expected if you run it on a slow machine. However you can configure it to be in-memory only and forward to syslog and you have it as it was before.
- XorNot 12y ago
  I'm highly suspicious that syslog can actually be faster in such a situation. If you can't seek to the disk quickly, then it doesn't matter what you do - logging will be slow if you need to flush frequently.

the_mitsuhiko 12y ago

> The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it. To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken because you can read the unbroken stuff. Going by the bug tracker the journald approach is to make the reader work with broken files better.

valarauca1 12y ago
This is like saying. "I get shot going to work every day. But I bought a bullet proof vest, so life is okay." Iron bandages don't solve problems, they for a short time work around them. Except because nobody actually like writing systems level code, they stick- forever.
- the_mitsuhiko 12y ago
  > "I get shot going to work every day. But I bought a bullet proof vest, so life is okay." You get corruption if the machine shuts down incorrectly. In binary or text files. In that case journald/syslogd act like a black box. Syslogd will give you whatever garbage it has in those text files, journald will give you the surviving records and will tell you which ones are unreadable. If you want to not get shot, shut down your machine properly. If you cannot shut down your machine properly because it crashed then you have data garbage if you want it or not. Drives work that way. I'm not sure what you are arguing for. Journald does not write broken records itself.
XorNot 12y ago
The binary logs are append only. The bug tracker entry says that they got "some corrupted logs" but not how. People get corrupted or truncated text logs all the time, they just ignore it because "oh the log ends midway through a line? eh". The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technical accuracy or discussion.

ape4 12y ago

I googled "libqrencode". Is it really QR code encoding?

the_mitsuhiko 12y ago
Yep. It's because when you kernel panic most people do not feel like typing stuff off a screen. If you have a QR code on your monitor however you can easily scan it and it contains all the info about what is wrong. That's a pretty good feature if you ask me.
- ape4 12y ago
  That is a useful feature! The way it was written it sounded like QR codes were going into the logs.
- uselessdguy 12y ago
  That's a Linux kernel feature, not a systemd feature. It's unrelated: http://www.linux.com/news/featured-blogs/200-libby-clark/773488-opw-intern-develops-qr-code-for-linux-kernel-oops-messages http://www.linux.com/news/featured-blogs/200-libby-clark/773... systemd has libqrencode integration, in order to, if I recall correctly, display a QR code when you generate FSS keys from journalctl.