From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 23013138E20 for ; Fri, 21 Feb 2014 21:04:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 96BB0E0F37; Fri, 21 Feb 2014 21:03:57 +0000 (UTC) Received: from smtpq2.gn.mail.iss.as9143.net (smtpq2.gn.mail.iss.as9143.net [212.54.34.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 5E3C4E0F00 for ; Fri, 21 Feb 2014 21:03:56 +0000 (UTC) Received: from [212.54.34.137] (helo=smtp6.gn.mail.iss.as9143.net) by smtpq2.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WGxGF-0002Wj-Or for gentoo-user@lists.gentoo.org; Fri, 21 Feb 2014 22:03:55 +0100 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp6.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WGxGF-0001a0-78 for gentoo-user@lists.gentoo.org; Fri, 21 Feb 2014 22:03:55 +0100 Received: from www.antarean.org (net.lan.antarean.org [10.20.13.13]) by data.antarean.org (Postfix) with ESMTP id E01004B for ; Fri, 21 Feb 2014 22:03:26 +0100 (CET) Received: from 10.55.16.19 (SquirrelMail authenticated user joost) by www.antarean.org with HTTP; Fri, 21 Feb 2014 22:03:26 +0100 Message-ID: <938dd748c8ef83bc9826544524015375.squirrel@www.antarean.org> In-Reply-To: <53061C57.4090103@gmail.com> References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <53010A8E.2050909@googlemail.com> <53012691.6040503@googlemail.com> <5ea6afc66880871ddec1398bab1e1f17.squirrel@www.antarean.org> <31f183759cbab018caa5523ab4974175.squirrel@www.antarean.org> <5305C7E3.9030906@yandex.ru> <53061C57.4090103@gmail.com> Date: Fri, 21 Feb 2014 22:03:26 +0100 Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org User-Agent: SquirrelMail/1.4.22 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Ziggo-spambar: + X-Ziggo-spamscore: 1.2 X-Ziggo-spamreport: BAYES_50=0.8,RDNS_DYNAMIC=0.982,RP_MATCHES_RCVD=-0.574 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 6082096b-b826-400a-9e9a-e7564f614abb X-Archives-Hash: 905f6db921dfe100ef3c9fab69627a2d On Thu, February 20, 2014 16:16, Alan McKinnon wrote: > On 20/02/2014 11:16, Yuri K. Shatroff wrote: >> >> >> 20.02.2014 09:24, Canek Pel=C3=A1ez Vald=C3=A9s =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: >>> [ 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 fo= r >>> SSH, from February 12 to February 15? Done: >>> >>> journalctl --since=3D2014-02-12 --until=3D2014-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 i= n >> one single file, not split into files by date, service etc, so that th= e >> whole O(n) issue is moot. > > I have logs like that. It's not an uncommon scenario. I've seen logdirectories containing a a few hundred MB of logs on a test environment with a single user doing just one thing. Fortunately, there was a single file which indicated which of the 200+ files contained the actual error message I was looking for. >> I believe it would be a 5-minutes job to add the capability of printin= g >> last N log entries for a service to `rc-service status`. Using cat, gr= ep >> 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. Would journald? >> Not reinventing wheels. Not spending super-talented >> super-highly paid developers' time on doing tasks one had done about 3= 0 >> 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 me= ss. > > 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. Replace "perl" for a different 4-letter world depicting a language commonly used for enterprise applications supported on multiple platforms and you get what I have to deal with. One of those has the more commonly needed logs in 4 or 5 locations. This can easily end up being a lot more, depending on how it is being used. A script to find all those would need admin-level permissions into the application itself to query information needed to find the logfiles. Another application I worked with in the past had 20+ locations. A few of which contained 100+ logfiles after a few days of use. At least 5 of thos= e didn't even have time-stamps. For those, a clever utility would be useful, but if I could write that, I'd use those AI-routines to take over the world ;) -- Joost