On 8/7/2014 8:28 PM, AW wrote: > On Fri, 8 Aug 2014 09:03:56 +0900 > Joel Rees <joel.r...@gmail.com> wrote: > > > You do understand the chicken-and-egg nature of what you're asking for? > > > > You're needing to output logs to but up servers, but you have to boot > > a server as complex as anySQL server to get there. > > I wasn't going to continue on this thread -- and after playing with > the journalctl cli for much of the day -- I repent of my complaints [mostly] > -- any remaining complaints are extremely minor. But I guess I should answer a > direct question... perhaps a new thread should be started, this one is getting > long in the tooth. > > Of course I understand the chicken-egg problem. However, once the system is > running, there's no reason why the log data collected during the boot > process couldn't then parsed into a standardized db --- resulting in > standardized sql query capabilities. The boot log data should be entirely > ASCII until a login prompt. This greatly assists troubleshooting of failed > boots - undeniably. However, after booting, remove the ASCII boot log data > from RAM via secure deletion process to increase security of the system as a > whole... > > --Andrew > >
I just wonder - why should I have to look in multiple paces for (possibly related) messages? That is, some to a text file, some to a SQL file. I have nothing against SQL (I've been using it for over 25 years). But I don't think it's a good solution to everything. Not everything is relational (which is what SQL excels at). And not everything needs a SQL engine when text files work just as well. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e425d1.8080...@attglobal.net
