3 ms·
> The interface to journald is more complicated than it should be but it’s also really powerful I thought the point of logging to stdout (i.e. docker logs) is
by deckard1 6y ago
> The interface to journald is more complicated than it should be but it’s also really powerful
I thought the point of logging to stdout (i.e. docker logs) is that you just take that output and dump it to another server for processing and filtering.
journald/journalctl seem to be a solution a few decades late to the party. For a single user machine or a single app prod environment, I would take a plaintext log any day of the week. At least I can remember how to grep the damn thing. And then when you get to a distributed system, what's the point of journalctl? You would hopefully have all of that logging aggregated together in one place with a much nicer web interface for it all.
- throwaway894345 6y agoExactly this. I just want a stream of logs that I can process with ordinary unix tools without jumping through hoops. I don’t need any extra power for its own sake.
- Spivak 6y agoIf that’s all you want there’s really no hoops. journalctl | grep Does what you would expect, it will happily (and by default on most distros) forward to syslog if you want files. The big ease-of-use win for journald is that it captures process stdout. No need to run daemons in the foreground ever.
- throwaway894345 6y agoclose, but it’s actually sudo journalctl -u $service -f | grep Not a huge deal, but I have to google it every few months because I don’t use it very often. Note also that if I just want the log stream, I have to pipe through less to get the full log messages. There’s also a flag for it, but I can’t remember my workaround is easier than digging through man pages. Again, no big deal, just friction. Like everything in the systemd ecosystem—everything is manageable, but it’s tedious.