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

Reply via email to