3 ms·

> 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 sys

> 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.

dale_glass 3y ago
> 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.
- zlg_codes 3y ago
  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.
  - dale_glass 3y ago
    > 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.

dale_glass 3y ago

> 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.

zlg_codes 3y ago
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.
- dale_glass 3y ago
  > 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.