Re: [blfs-support] Systemd's journal (was Re: Latest news in GNOME world)

2012-11-12 Thread Matt Burgess
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


Re: [blfs-support] Systemd's journal (was Re: Latest news in GNOME world)

2012-11-12 Thread Aleksandar Kuktin
WARNING!! FLAMEBAIT!!!


On Mon, 12 Nov 2012 15:26:08 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:

 Third, if the logs were ascii, the bells and whistles in the link
 above could be accomplished with a bash script fairly easily.

FLAMEBAIT, USE ASBESTOS!

Well, since UNIX and clones have survived all these years, I believe it
is safe to bet they will continue surviving. :) After all, sysvinit
itself has, what, 30 years under its belt?

-- 
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page