4 ms·
Good point, but not my example.[1] I found it a bit weak tbh. I think a more common and compelling case is where you need to treat the system log as a file inpu
by coolj 13y ago
Good point, but not my example.[1] I found it a bit weak tbh. I think a more common and compelling case is where you need to treat the system log as a file input to some existing tool / system. Sure, you can install a traditional logger if you need it in such a case, but what do you gain by not including it? A little bit of disk space?
I wonder if there's an unstated motive behind the proposal to promote a more pervasive use of systemd. I mean, being honest, admins aren't going to go to the journal unless they need something the traditional log file doesn't provide (which would be rarely if rsyslog and ilk are pulling everything they can out of journal anyway).
Nobody is going to switch to journalctl | fgrep OMGERROR unless they have to (well, they won't have to, but admins are lazy, and if that's the default way, then they will use it rather than installing a new package). Just look how long it took (is taking) for admins to move to ip vs ifconfig/route/etc...
[1] http://article.gmane.org/gmane.linux.redhat.fedora.devel/182278 http://article.gmane.org/gmane.linux.redhat.fedora.devel/182...
- ciupicri 13y agoBy the way, journalctl already has some built-in filtering, e.g. journalctl PRIORITY=3 _SYSTEMD_UNIT=xxx.service