[arch-general] When will Arch switch to Systemd

[Tom Gundersen]

On Fri, Jan 21, 2011 at 3:07 AM, Heiko Baums <lists at baums-on-web.de> wrote:
> 1. A possible loss of control over my system due to many unnecessary
> automations and dynamizations.

I agree that the user should be in control of his system. If you find
any examples of loss of control, please file bug reports or send an
email, I'd be happy to follow up on it.

> 2. I don't like automounting. I want to have control over my drives and
> partitions and want to decide which partition is (auto-)mounted
> (that's what /etc/fstab is for) or not.

Unless you actively enable automounting (which is really cool btw) it
will not be used.

> 3. Parallel booting (staring several daemons parallel at boot time) can
> make booting significantly slower particularly on older and slower
> systems. Serial is quite often a lot faster than parallel. The harddisk
> can only make one read or write access at a time. So there's hardly
> benefit of starting daemons (reading them from the harddisk) parallel.
> Btw., such a parallelization of starting daemons is already possible
> with Arch's and Gentoo's sysv init system. So systemd is not needed for
> that.

There are work underway to deal with this (and in my experience it is
already dealt with by the simple readahead implementation that comes
with systemd), again bug reports are welcome (bootchart2 is a great
tool for this).

> 4. Somewhere (I can't remember where) I've read that systemd starts
> daemons only when they are needed. So if the daemons aren't started at
> boottime but later than it's obvious that the system is booting faster.
> But starting the daemons at runtime will take this saved time later,
> means you first have to wait longer for the daemon to be started and to
> be able to use its service for the first time. And again there's the
> point of loss of control over the system. I want to decide when a
> daemon is needed and when a daemon shall be started, and I don't want
> another daemon to decide that.

You have the choice in systemd between starting the service as soon as
possible or (if the service supports it) as late as possible. The
former would be used for services that are used most of the time, the
latter for services that are seldom used.

> 5. In the same article I read that systemd binds itself to port 80
> instead of starting apache at boottime and starts apache only if a
> request to port 80 comes in. This is not the task of an init system, and
> I have slight security concerns about that. If I tell the init system
> that I want apache being started then I want to have apache started at
> boottime or when I say so and not when systemd thinks it is needed.
> And this way systemd first needs to unbind itself from port 80 and then
> start apache and bind it to port 80. So if I open port 80 in my firewall
> this port is open without a software being bound to it, even if it's
> only a millisecond.

This functionality would be opt-in (it is not there yet for the case
of apache), and if the attack vector you outline is valid I can assure
you that this would not be allowed upstream.

> 6. There's again an additional daemon which is always running in the
> background and eating unnecessarily system resources which could much
> better be used for the programs which are really used.

This I doubt is a real issue. The memory footprint is tiny, and most
of the time it will be swapped out. If you have some numbers showing
me wrong, this would be a bug I'd be happy to look into.

> 7. I'm using LVM and harddisk encryption. So systemd seems not to work
> for me anyway.

This should work. However, we desperately need testers for this (as
the LVM support is not upstream, but written by yours truly, based on
the Arch initscripts).

> Regarding the arguments about having more control over started daemons.
> Have you guys already read the boot messages? There are such nice
> messages "[BUSY]", "[DONE]", "[FAIL]" at the end of almost every line.
> And there's /var/log, dmesg and tools like ps, top, htop, etc. For my
> part I have total control over my running or not running daemons and
> other software.

There is quite a lot more to controlling daemons than this. I'd
recommend having a look at the blog entries linked to in the beginning
of this thread.

> I'm not quite sure if I'm right with my concerns, because I haven't
> tested systemd and don't know much about it, yet. So, please, correct
> me if I'm wrong and explain it. But I don't like too much automation
> and dynamization anyway, because it easily can make things worse and
> lead to loss of control over the system.

If you want to try out systemd and have any problems/questions let me
know. (If you prefer to stick with sysvinit, that's fine too ;-) ).

Cheers,

Tom