On Mon, 2012-11-12 at 15:26 -0600, Bruce Dubbs wrote: > Matt Burgess wrote: > > On Mon, 2012-11-12 at 11:56 -0600, Bruce Dubbs wrote: > > > >> What advantages does systemd give? > >> > >> Binary logs? That's a little difficult to work with if Xorg isn't > >> working. How do you grep a binary log? > > > > I was going to say 'me too' to all of your post, Bruce, but then, in > > trying to find the list of 18(!) guides on how to use the various > > components of systemd came across > > http://0pointer.de/blog/projects/journalctl.html which describes how to > > access the binary logs. The features it provides all seem pretty neat > > and all accessible from the command line. So, that's one less thing for > > me to hold against it. > > > OK, let's discuss this. My first comment is that when you have custom > programs like this, the author has to think about everything an admin > might ever want. What if the admin wants something the author didn't > think about?
It's open source, they can just extend it :-) > Second is that you are using different tools from other logs such as > apache, ftp, mail and any other application that writes a log. >From my brief reading, it looked as if, if the service is controlled by systemd, the journal will collate its logs. In this respect, it's a lot like things like logstash (http://logstash.net/). I *think* logstash keeps its own copy of the logs, thereby doubling logging capacity, and then adds an indexing overhead as well. Again, I *think* journalctl just stores the one copy, and will presume it also needs additional space for indexing. Whilst logstash requires the admin to configure the inputs, filters and outputs, it looks as though journalctl works out of the box. > Third, if the logs were ascii, the bells and whistles in the link above > could be accomplished with a bash script fairly easily. Maybe my bash-fu is a bit rusty, but collating multiple sources of logs together, then filtering them back out again to drill down with the flexibility that journalctl provides would have me googling for a piece of software to do it after about an hour, I think :-) Note that for home-user systems, I wouldn't bother with journalctl at all, but on the enterprise environment's I have to support, I'd want something like this to make cross-service log analysis much easier. > About the only really sensible argument is that binary logs use less > disk space. In the days of TB drives, even that isn't a big deal. I'm not sure I'd even class that as a sensible argument. > To me the whole systemd philosophy moves away from user knows best to > developer knows best. That's just like MS and Apple. The difference of > course is that systemd *is* open source and we don't have to use it. No, we don't have to use it, and I'm still not suggesting anyone does :-) I'm just pointing out that I can see the utility in journalctl. My jury's still out on systemd's service and resource management though; and I don't think you can have either resource or log management without the service management component. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
