Are they really "terrible" with "awful usability"? In my day-to-day debugging, I do find `journalctl` much better.
Let's see a couple of quick examples:
- Show logs for the current boot: $ journalctl -b
- To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err
- Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd
- Or via its unit file: $ journalctl -u libvirtd -l
- Want to query all the errors for a given disk? Here we go: $ journalctl /dev/sda -p err
I quite like journalctl, but the naming could be better. 'system' means OS, and kernel, and init system, and computer, and many other things. 'start-service' would have been better.
The worst is 'system-cat' to send a log message (SysVInit used 'logger'). Why not just 'log'?
Ok, then you've traded one command with switches for multiple commands each with their own set of switches (and almost certainly following different switch 'standards'). I like systemctl/journalctl for cleaning up that mess, even if it requires me to learn how to use them.
Then you will have an awful salad of separate commands that you have to juggle around. I am all for "UNIX philosophy" within reason; it has its bounds, let us not over-romanticize it.
- Show logs for the current boot: $ journalctl -b
- To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err
- Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd
- Or via its unit file: $ journalctl -u libvirtd -l
- Want to query all the errors for a given disk? Here we go: $ journalctl /dev/sda -p err
And so on...