Systemd 219 Released With A Huge Amount Of New Features

[phoronix]

Phoronix: Systemd 219 Released With A Huge Amount Of New Features

Lennart Poettering announced the release of systemd 219 today and it comes with a very large number of new features and changes...

http://www.phoronix.com/scan.php?page=news_item&px=systemd-219-Released

[ihatemichael]

Great, now if they would only fucking fix journald to not corrupt logs anymore, I'm so fucking tired of doing `journalctl --verify` just to see a bunch of corrupted logs showing as FAIL.

Why can't they implement a `systemctl --fsck` to actually fix those corrupted logs?

systemd is such a failure and a cancer.

I want my old logs back and not this piece of binary and corrupted shit.

[Pseus]

Great, now if they would only fucking fix journald to not corrupt logs anymore, I'm so fucking tired of doing `journalctl --verify` just to see a bunch of corrupted logs showing as FAIL.

Why can't they implement a `systemctl --fsck` to actually fix those corrupted logs?

systemd is such a failure and a cancer.

I want my old logs back and not this piece of binary and corrupted shit.

Huh? Corrupted logs? I am not seeing that. In any case, you can setup journald to forward logs to whatever logging daemon you prefer, wouldn't that fix your problem (as you don't want to use journald in any case)?

[ihatemichael]

Huh? Corrupted logs? I am not seeing that. In any case, you can setup journald to forward logs to whatever logging daemon you prefer, wouldn't that fix your problem (as you don't want to use journald in any case)?

No, that only increases complexity and I actually want to use the journal but I can't trust it as most of the logs tend to get corrupted.

systemd/journald is known for getting logs corrupted and developers are indifferent about that.

See this bug report to see what I'm talking about:

https://bugs.freedesktop.org/show_bug.cgi?id=64116

P.S: just implement a fucking `journalctl --fsck` to help fix this mess and get over your egos. You are hurting your users and Linux with this pile of broken shit.

[tomegun]

No, that only increases complexity and I actually want to use the journal but I can't trust it as most of the logs tend to get corrupted.

systemd/journald is known for getting logs corrupted and developers are indifferent about that.

See this bug report to see what I'm talking about:

https://bugs.freedesktop.org/show_bug.cgi?id=64116

P.S: just implement a fucking `journalctl --fsck` to help fix this mess and get over your egos. You are hurting your users and Linux with this pile of broken shit.

Did you read the comments on the bug. It is explained there:

Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

[RahulSundaram]

See this bug report to see what I'm talking about:

https://bugs.freedesktop.org/show_bug.cgi?id=64116

P.S: just implement a fucking `journalctl --fsck` to help fix this mess and get over your egos. You are hurting your users and Linux with this pile of broken shit.

I would give your advice back to you. See the bug report yourself.

https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3

Also repeated again.

"Again, the journalctl tries hard to salvage all data from the unit files, should there be a corrupted one, and it does this implicitly, all the time, when showing them."

[Ericg]

Interesting feature.

* When the user presses Ctrl-Alt-Del more than 7x within 2s an
immediate reboot is triggered. This useful if shutdown is
hung and is unable to complete, to expedite the
operation. Note that this kind of reboot will still unmount
all file systems, and hence should not result in fsck being
run on next reboot.

[asavah]

I don't care. What part of I DONT WANT CORRUPTED LOGS ON MY SYSTEM IN THE FIRST PLACE did you not understand?

Jesus fucking Christ, these systemd people are fucking morons.

Corrupted logs were never even a problem with rsyslog/syslog-ng because that never happened with those tools. Now systemd is giving us corrupted logs, that's what I call "progress".

Piece of fucking shit.

True that.
I never liked the idea of *binary* logs.

Can't say I'm a systemd hater, but everything Pothead touches is instantly turned into shit.

[ihatemichael]

It does seem like I will actually have to disable binary logs and enable rsyslog forwarding, because while that's more complex, it's at least more reliable than the brain damaged journald.

Anyway, thanks systemd for giving us broken/corrupted binary logs and not a way to fsck them.

Deep sigh.

[Ericg]

I don't care. What part of I DONT WANT CORRUPTED LOGS ON MY SYSTEM IN THE FIRST PLACE did you not understand?

Jesus fucking Christ, these systemd people are fucking morons.

Corrupted logs were never even a problem with rsyslog/syslog-ng because that never happened with those tools. Now systemd is giving us corrupted logs, that's what I call "progress".

Piece of fucking shit.

No.. you don't KNOW whether or not rsyslog/syslog-ng were giving you corrupted logs because there wasn't a check FOR corrupted logs. You would've never known, at least with journald you get told "Hey, for whatever reason, maybe my fault, maybe disk's fault, part of this log is lost."