[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Init system deba{te|cle}

On 11/04/2013 12:22 PM, Tom H wrote:

On Mon, Nov 4, 2013 at 4:37 PM, Conrad Nelson <yaro@marupa.net> wrote:

On 11/03/2013 10:41 AM, Reco wrote:

On Sun, 3 Nov 2013 14:21:40 +0000
Jonathan Dowland <jmtd@debian.org> wrote:

On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote:



Well, there are some nice features in systemd. It's easier to work with unit
files over shell scripts. It's nice to write out how you want the system to
manage services in a declarative style over an imperative one. Also, teh
dependency/concurrency-based startup makes a properly set up systemd boot up
a Linux system very fast.

What's maybe not so nice is the journal. It's great to be able to search it,
but I rather like not having my logs stored in a binary format for a feature
that, while nice, might not see much use on my system. :/ I'd still rather
be able to just open logs in a text editor and parse through myself.
Fortunately systemd has no qualms about passing system events to stuff like
syslog (And adds a few useful things to the logs to boot.)

I agree with the last sentence. All you have to do is pay a visit to
"/etc/systemd/journald.conf" and set "Storage=none" and
"ForwardToSyslog=yes" (and have rsyslog running!).

But journalctl is a wonderful tool (at least in IMO).
Oh, it is. I think a better way to put what I mean is "journalctl is great as long as it's still letting things like syslogd have a copy." Which is great because journalctl makes it pretty trivial to do exactly that. This way I can use whatever I want to look at logs, which is handy in a rescue situation. Unfortunately I don't have a lot of need to use jornalctl's nicer features. 




Upstart has the right idea but the wrong implementation. You'd be hard set
to see anyone care to use it outside of Ubuntuland and it's not just purely
for the fact it's got ties to Canonical. I think the most classical example
used is its dependency approach. Rather than bring up a service if another
service calls for it, it brings up a service, then brings up EVERY LAST
SERVICE IMAGINABLE THAT USES IT. Imagine what it's like to launch your
network service and see sshd, httpd, telnetd, and a Minecraft server all
launch because their configuration states they use the network service
(Unless you disabled it.).

That's the whole point of upstart events. If you don't want a network
daemon to start when the network comes up, change it to manual with
"echo manual > /etc/init/<daemon>.override". Aren't all these daemons
brought up at boot (perhaps not simultaneoulsy) when you're using
sysvinit unless you disable them?
In systemd, this would not be necessary, though. Systemd approaches it in the reverse way. It simply says, "X service is required by Y service, therefore I'll start Y so X can use it. Once X is done, I'll go ahead and shut down Y to save memory and CPU time." Upstart, by default, says, "X has been started. Since Y, Z, A, B, and C can use it, I'll go ahead and start those regardless of performance/memory impact or actual need for those services. And I don't think I'll bother shutting any of these down unless explicitly directed."
Yes, you can change the configuration for those services, but the point is that it shouldn't be necessary to do so. A smart init shouldn't think that because a service is available EVERYTHING ELSE that depends on it needs to be run by default. This is why I think systemd is great and upstart is not. Upstart has the concept (Dependency-based event-driven service management.), but the execution of the concept is lacking.
Sysvinit is worse, though, since its reliant on shell scripts to do virtually everything you'd think init should probably handle itself. There is perhaps a loss of flexibility in setting up a system configuration with systemd, but looking back at my time with Arch I realize that flexibility isn't really essential and the downsides weigh down sysvinit. 

Conrad
Reply to: