Scheidler: Project Lumberjack to improve Linux logging [LWN.net]

Scheidler: Project Lumberjack to improve Linux logging

Posted Mar 4, 2012 9:10 UTC (Sun) by khim (subscriber, #9252)
In reply to: Scheidler: Project Lumberjack to improve Linux logging by anselm
Parent article: Scheidler: Project Lumberjack to improve Linux logging

It seems to me that all the »hackability« is actually there – it's just not required in many cases because the infrastructure that systemd already provides is adequate.

The problem here, of course, is the fact that most services will not come with SysV init scripts which can be “slightly altered”. It's the same story as with “PHP” vs “___ language”. The ability to easily change things in production is both really nice (and this is what “sysadmins” clamor for) and completely horrifying at the same time.

I welcome systemd with both hands exactly because I have worked as sysadmin and I know “both sides” of the equation. It's just not worth it. If you really need to hack something - you can do that with systemd. But this will be highly visible and traceable (you'll get new large file in mostly-empty directory, not two lines added to large pile of scripts god knows where).

As far as »transparency« is concerned, systemd is also a big step forward since one does not need to analyse the init script for every single service separately to find out exactly how that service is started; looking at the (much shorter and simpler) systemd service file will suffice.

I think “transparency” here means something like “the ability to insert "set -x" in your script to see what really goes on here”. Yes, systemd is more opaque in his work, which is kind of unfortunate, but this [small] problem is more then compensated by it's advantages: I'm saying this, again, as former sysadmin - the fact that Linux had no way to reliably kill service before systemd was created is just crazy.

(Log in to post comments)

Scheidler: Project Lumberjack to improve Linux logging

Posted Mar 8, 2012 17:16 UTC (Thu) by sorpigal (subscriber, #36106) [Link]

I have a sort of love-hate relationship with both systemd and SysV. I like a lot of things about systemd, but the anti shell script crusade is a big turn off. I like that SysV is "simple" in that while there's a lot you need to do "just so" to do it right, the process is simple to explain and wrap your head around. With systemd it's harder to make sense of what its model of operation is, especially because it *does* handle all sorts of different cases with its different options. Eventually you can pore through the man pages and get the picture for any given piece and eventually I may grow familiar with all the options to the point where I find it easy to know what's happening, but meanwhile it sure doesn't *seem* as nice as "simply" reading through a shell script and everything it sources. And yeah, set -x makes tracking down problems a lot less mysterious than other init systems.

And then... sometimes I want to review "all messages emitted during boot" and find that I can't, then I curse sysvinit's idiocy, demand to know why I have to jump through hoops to answer questions like "Why was this process started and do I need it?" and at these times I smile fondly at systemd. Until something breaks and I open a config file which has a parameter that does who-knows-what set to a value that means who-knows-what will happen at who-knows when.

I never want to be sitting at a Linux box experiencing what I like to call "That Windowsy feeling." You know, the one you get when you realize "I can't tell what happened. It just happens, I'll never know why it happens, I'll never be able to understand what it's doing, and I can't think of a thing to do to diagnose it." As long as systemd never leaves me feeling like that then it's A-OK.