Hacker News Reader

Comment by zlg_codes | Hacker News Reader

Yeah dude I totally love it when journald eats my logging and power interruptions create unrecoverable log loss! You can forget just mounting a drive and checking its journald logs -- your machine has to be started by systemd in order to read journald logs!

I totally love it when liars frontmanning the project say it's a project and an init system and a system layer that will replace everything. But it won't! Pay no attention to the inconsistent messaging, the "gentle pushes" to get other distros to use it, etc. Also, let's not mention he basically hoodwinked the entire community by switching teams to Microsoft. And people like you eat his work up! Are you sure you like free software?

View on HN

> Yeah dude I totally love it when journald eats my logging and power interruptions create unrecoverable log loss!

So does everything else, because of consumer drives. Fun fact: filesystems by default only guarantee the integrity of the filesystem's structure itself. The promise is that after power loss, the basic structures of the filesystem won't be corrupt, but makes no big claims of reliability about the data written. Blocks of random junk in your data, blocks of NULLs, even parts of other files (maybe deleted data) are all things I've seen happen.

Databases and the like take serious effort to ensure safety, but that greatly slows down performance. So it's kind of a hard sell for a log system that's not supposed to be a performance impact.

For this contingency, you can do log shipping, but in general, system logs shouldn't be expected to be reliable in the face of a crash, since to my knowledge all normal daemons (including rsyslogd) buffer data before flushing to disk.

> You can forget just mounting a drive and checking its journald logs -- your machine has to be started by systemd in order to read journald logs!

No, it doesn't. There are file arguments to journalctl. Read the manpage, sheesh.

> I totally love it when liars frontmanning the project say it's a project and an init system and a system layer that will replace everything. But it won't! Pay no attention to the inconsistent messaging, the "gentle pushes" to get other distros to use it, etc.

Meh. Paranoia.

> Also, let's not mention he basically hoodwinked the entire community by switching teams to Microsoft. And people like you eat his work up! Are you sure you like free software?

Free Software is a licensing/distribution concept completely unrelated to whether one likes or not Microsoft's technical decisions. Some I really hate, and some are actually pretty cool.

I'm for Free Software because I like the licensing philosophy, not because I believe Unix is the best thing since sliced bread. In fact I believe Unix started as a bunch of good ideas but that have not kept up and so needs a bit of work to remain a good system to use.

> No, it doesn't. There are file arguments to journalctl. Read the manpage, sheesh.

... And how are you going to produce the journal file to read? ... with systemd. If you broke the system and it won't boot, you'll need to boot from systemd and check with journalctl because the journal can't be accessed otherwise. That usually requires a liveUSB running systemd to pull off. This is why you don't use binary logs.

Compared to `less /var/log/messages` from any Linux, I know which one I'm trusting.

I like controlling my system instead of having it controlled for me, thanks.

> And how are you going to produce the journal file to read?

What do you mean "produce"? They were produced while it was running, they can be found in /var/log/journal

> If you broke the system and it won't boot, you'll need to boot from systemd and check with journalctl because the journal can't be accessed otherwise.

Obviously? I'm not seeing the problem. It's not like you're getting anything from that system without having a way to mount your XFS/Ext4/BTRFS/LVM/luks/whatever setup. You need to boot a distro compatible with that to do it.

So of course you have to boot a Linux distro, which will easily have all the tooling available, including to deal with the journald stuff.

It's just a complete non-problem.

> I like controlling my system instead of having it controlled for me, thanks.

I'm not sure what that means exactly.

This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss.

A sane system doesn't need a whole lot just to check logs. LVM and LUKS are different due to cryptographic needs. systemd meanwhile has little reason to store logs in binary format. The promises that are alleged are not concerns to anyone except enterprise.

> This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss.

I just don't buy the problem as legitimate. It's an aesthetic problem, not a real problem. Sysadmins clearly have no problem with the fact that XFS is not a human readable format, or I don't recall anybody making a stink about using Berkeley DB for a whole bunch of stuff.

> systemd meanwhile has little reason to store logs in binary format.

Quite a few actually. Indexing, transparent compression, clear storage of arbitrary amounts of data with well delimited fields, quick seeking. Makes for a compact and very well performing system.

You can't quickly seek a .gz text file, while journald will tell you what happened a week ago at 3 AM in a few ms.

> The promises that are alleged are not concerns to anyone except enterprise.

Or people who realize there's a bit more to logs than 'tail' and 'grep'.

Eg, journald trivially will give you a log from a given timeframe that interleaves the logs of a proxy, httpd, database and application server, actually producing a log in which a request can be logically followed through the different services it went through, with timestamps in microseconds.

In an application that's designed for it, you can actually ask for logs regarding to a given host, user, etc.

If you've ever done log parsing, well, now you don't need to ever write a regex to split a .log by fields, because that was already done for you, and you can have UNIX timestamps directly instead of doing date parsing.

Reply on news.ycombinator.com