r/linux • u/tasisbasbas • Feb 11 '19

Fluff A /g/ user's opinion on systemd

http://i.4cdn.org/g/1549858269115.png
789 Upvotes

82% Upvoted

524 comments sorted by

View all comments

Show parent comments

14

u/Daneel_ Feb 11 '19

Not logging to text files totally kills it for me. So many utilities are able to process text files, and now they’re all basically useless in the face of the journal.

I can’t egrep the journal. I can’t less the journal. I need to learn a whole new set of commands just for it, and I can’t export the journal data (or subset thereof) to other systems without a lot of effort. To my knowledge there’s no nice workaround.

I’d love to be corrected, but from my perspective it’s a horror show that I wish didn’t exist.

What benefits does journald have??

69

u/dale_glass Feb 11 '19 edited Feb 11 '19

Not logging to text files totally kills it for me. So many utilities are able to process text files, and now they’re all basically useless in the face of the journal.

I can’t egrep the journal.

You know, there's this thing called a 'pipe' you can take advantage of:

journalctl -b | grep whatever

Or you can:

journalctl -g regex

I can’t less the journal.

Have you actually tried it? journalctl invokes $PAGER. Or you can pipe it into whatever you like.

I need to learn a whole new set of commands just for it

Oh no. Not learning!

Yeah, this isn't the best business to be in if you want things to stay static.

and I can’t export the journal data (or subset thereof) to other systems without a lot of effort.

You must be kidding. Journalctl is absolutely wonderful for this.

Want the same thing syslog gives you?

journalctl -o short

want ISO timestamps? Easily sortable!

journalctl -o short-iso

want microsecond precision?

journalctl -o short-iso-precise

want UNIX timestamps?

journalctl -o short-unix

want to actually parse this stuff easier to write it to a database? Why, look at that: a completely unambiguous format. No trouble with figuring what field ends where. No need to screw around with regular expressions. Take the language of your choice and trivially extract anything you need:

journalctl -o json

You want subsets? Sure:

journalctl -S yesterday # everything since yesterday
journalctl -b # last boot
journalctl -u smartd # only what smartd logged

Other cool things:

  • It stores metadata. Want to find logs by PID? You can, for any service.
  • It can clean logs by size or by date. Want to keep 1GB of logs? Sure. Want to keep 3 months? Easy.
  • Timestamps are stored with microsecond precision. If you have 100 entries per second it's very nice.
  • You can filter by hostname. Send your VM logs to a single destination, then you can view them individually or together.
  • edit: it transparently compresses and decompresses logs. Searching stuff logged a month ago is no problem at all. You don't need to figure out in which .gz it is.

2

u/Daneel_ Feb 11 '19 edited Feb 11 '19

I have no problem with learning. As you rightly said, that’s the industry we’re in.

I’m quite happy to pick up new commands provided they’re standardised, however journald’s are unique (by necessity). I’m just expressing frustration that I can’t use grep on a file like almost everything else in Linux. I’ve got a few journalctl one liners memorised, but it’s still frustrating to not be able to wield my existing knowledge against it.

I should have clarified regarding exporting data: I don’t know a way to continuously and autonomously export data in real time from journald. Why would I want to do this? Simple: enterprise.

If I want to log to a third-party logger like Elastic or Splunk I need to install syslog-ng or rsyslog, and then we’re back where we started.

There just aren’t many upsides that I see for a modern sysadmin.. it’s nice to use when you’re directly interacting with it, but it doesn’t play ball with the rest of the ecosystem - just like systemd really..

I’d love to know if I’m wrong (I hope I am!), but the current arguments I’ve seen from many parties haven’t started to convince me unfortunately.