On 20/02/2014 11:16, Yuri K. Shatroff wrote: > > > 20.02.2014 09:24, Canek Peláez Valdés пишет: >> [ snip ] >>> but I do not see the point, beyond as a nice gimmick. >> >> Well, I *do* see a point. Many points, actually. You want the logs for >> SSH, from February 12 to February 15? Done: >> >> journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service >> >> No grep. No cat. No hunting logrotated logs (the journal will rotate >> automatically its logs, and will search on all logs available). You >> can have second-precision intervals. >> >> Also, the binary format that the journal uses is indexed (hence the >> binary part); therefore, the search is O(log n), no O(n). With a log >> with a million entries, that's about 20 steps. >> >> Perhaps it's just a gimmick to you. For me is a really usefull > > Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) > if really needed is easily achieved with databases. > Not using cat and grep is not something one'd boast; rather, again, a > waste of resources to recreate already existing tools. > BTW, I wonder if anyone does really have logs with millions of lines in > one single file, not split into files by date, service etc, so that the > whole O(n) issue is moot.
I have logs like that. It's not an uncommon scenario. > Well, maybe it'd be nice to have a collection of log management tools > all-in-one but beyond that I don't see any advantages of systemd-journald. The immediate feature-add that syslog needs is arbitrary facilities, not the 16 fixed ones in syslog() system call. >> Its raison d'être is the new features it brings. > > I didn't notice any new features. It's not features that are new, but > just a new implementation of old features in a more obtrusive way IMO. > >>> Additionally, the use of "tail -f" and "grep" allows me to check the >>> logs >>> real-time for debugging purposes. >> >> journalctl -f >> >> Checks the logs in real time. Again, [1]. > > Again, a brand new Wheel(c) > >> systemctl status apache2.service >> >> (see [2]) will print the status of the Apache web server, and also the >> last lines from the logs. You can control how many lines. You can >> check also with the journal, as I showed up. > > I believe it would be a 5-minutes job to add the capability of printing > last N log entries for a service to `rc-service status`. Using cat, grep > and the like. No, that will not work easily for all definitions of easily. rc-something has zero control over where the logs go and no standard method to provide "hints" to the logger. Gentoo ships syslog* configs that basically stick everything in messages, where grepping them out is a PITA. I usually rewrite that config more to my taste and needs and rc-service cannot know what I did. So the idea fails at step 1 as the code does not know where the logs are. > Not reinventing wheels. Not spending super-talented > super-highly paid developers' time on doing tasks one had done about 30 > years ago. I believe, not having this option is due to its simple > uselessness. 30 years ago we had isolated stand-alone machines without nothing like the logging needs we have today. Whilst I agree with you that systemd's logging tools may not be the solution, I can assure you (as someone who has to deal with this shit) that syslogging in the modern world is a mess. Try this: Decide you cannot afford Splunk, so do it yourself. Now get your Apache access logs into the same searchable database your other stuff is in, and do it in such a way that you can SELECT what you want out in obvious ways. Repeat for every other app you have that logs stuff. Remember to find the really important logs which are usually sitting in /opt/ and produced by Log4Perl or something equally abominable. > > This way I really wonder if at some point the super talented systemd > programmers decide that all shell tools are obsolete and every program > should know how to index or filter or tail its output in its own, > though, open, binary format. I can't get rid of the idea that systemd > uses the MS Windows approach whatever you say about its open source. > -- Alan McKinnon alan.mckin...@gmail.com
