Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.
That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps.
"systemtctl" is a first class classic Linux/Unix tools that works together with all the standard Linux tools like sed, awk, grep, less, tee and what not.
It isn't interactive, it isn't chatty on success, can be piped etc, just like all the good ole GNU stuff. Sure, it can read binary text files like the journal, but so can "last" that is required to be Posix compliant (used to read the utmp/wtmp binary log files). And what about zgrep?
The systemd journal file format (basically an appended text file with non-standard delimeters+index) is fully documented and have excellent language bindings, making it trivial to make eg. Python scripts that read/writes directly into the journal. So it is trivial to make a "jgrep" or a "jless" that can directly read the journal if that is what you want.
The point is that "field" based logging is superior to the unstructured text dumps that syslog makes.
The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.
Come on, claiming that regular expressions are easy is laughable. The old joke "I had problem. I decided to solve it with regex. Now I have two problems" is still true.
Not talking about that people should know the difference between regular and extended expressions, and that each and every tool uses its own maddening variation. Basically, if you don't use regular expressions as part of your everyday job, you are unable to use it without heavy man-page consulting for just the basic syntax.
I seriously doubt that any more than a tiny fraction of Linux users are able to whip out an even moderately complex regex. And that means the vast majority of Linux users can't filter their logs to any serious degree. It is so sad to see how people are literally trawling through the logs, reading them as a book in order to find problems. People are even using "vi" to do it, yikes.
systemd's journal basically solves this problem for good for Linux newbies. It is fun to see how productive people can become with "journactl" after a 10 minute introduction.
For power users, the field based approach is immensely powerful too. If you remember how Rsyslog started a decade ago, it was exactly to overcome the many limitations of flat file text logs.
syslog severity level "error" and above
I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use.
It is a superb way to filter from both "that boot only" and "this severity only". One reason why you probably haven't tried it is because this is very hard to do using generic tools using flat file syslog text logs.
Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.
Even this is something journald does so much better than syslog; There is kernel guarantee that the source is always is always what it claims to be. Same with what program generated the log entry. It can even distinguish between two instances of the same program running simultaneously since each and every log entry is stamped with a unique id (and session ID, and machine ID so you can trail logs even if the hostname/IP changes or across multiple machines and OS containers).
As for time based filtering: I just love "journalctl --since -10m" (show everything that happened from 10 minutes ago) or "journalctl --since -3w -u smartd.service".
As for filtering per boot. If it had been easy to with syslog, I would have done so many times. Being able to only see the relevant boot is great, but it is also really powerful to compare two different boots using monotonic timestamps.
Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.
Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.
Actually I am old enough to have installed Slackware from 40 floppies (never again). Yes I have the O'Reilly books on sed, awk, bash etc.
But I see how you skipped my challenge, should be trivial since you claim it is CLI n00b stuff.
The point is that I am not the only one who thought that Linux logging have been a mess from the beginning. I had high hope when Rsyslog started, and they did fix several glaring errors, but in the end they failed because of the total lack of coordination in the Linux world. You can't really improve syslog, because then it wouldn't be syslog, and then userland don't support it. This circular dependency have been holding Linux back in several key areas.
The discussions of the many limitations of syslog, SysVinit, and X and Linux goes back to the previous century. It was just extremely hard problems to solve, so too many people have been confusing the longevity of SysVinit, syslog(3) and Xfree/X.org with any inherent quality. They all served their purpose in their time, but have been obsolete for at least a decade an a half. With systemd and Wayland, several of those systemtic problems have been solved for good, and that is something I really appreciate as a long time Linux user.
With some exaggeration, I think that using regex tools to do even basic log filtering is the perfect "Turing tar pit": "in which everything is possible but nothing of interest is easy.
Don't get me wrong, I like regex tools. Being able to utilise them is a major reason for why I like Linux so much, and the knowledge have of such tools have proven very useful many times outside Linux admin. But regex quickly becomes really unwieldy looking much like line noise. The main problem isn't the regex tools, but that syslog log files have such a loose structure. Having field based filtering just makes everything so much more powerful and easier.
