Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 08:21 PM, Steve Langasek wrote:
But unless you've only ever used Debian on systems with a flat
partition:filesystem structure, with no network filesystem mounts, no
LVM/RAID/LUKS, and no networks more complicated than a single interface,
you've either been affected by these race conditions, or you've been relying
on the chewing-gum-and-baling-wire workarounds that Debian has in place to
paper over these races. The problems are pervasive and systemic, and have
become progressively more severe over time as hardware becomes faster. An
init system that has not *fundamentally* addressed this class of problem
with its design is not bringing anything interesting to the table.
I fully agree with you here, Steve. NFS mounts (with or without autofs)
don't cope very well with fast booting machines as well as machines
with several (virtual or physical) interfaces. I don't know how often
I ended up with a machine on the network where half of the NFS
automounts weren't there until I restarted the autofs daemon simply
because autofs was initialized prior the network was properly working.
And, yes, the LSB init scripts contain the correct dependencies and
yet it doesn't work properly. An init daemon which makes sure that
a certain resource is properly configured or a daemon is really running,
is essential nowadays to boot sophisticated systems reliably.
I have also seen the need for resource management ala cgroups on our
large compute clusters. When dozens of users are using a very
large cluster simultaneously, you want to have the possibility to
limit the resources per user such that a single user won't be able
to bring down the whole cluster or have the OOM killer kick in.
I have seen users bring down a central login node because they
were smart enough to start a huge calculation on the login node
instead of actually queuing their job onto the cluster itself.
The people who have dismissed boot speed as a matter for toy systems are
being naive. It is not the number one priority for upstart or for anyone
else; but downtime costs money, just as inefficient power control on systems
costs money; and time spent booting is downtime. Time spent improving the
boot speed for the millions of systems that run Debian is time well spent.
systemd (and upstart) actually show their fast booting in virtual
machines which are very common nowadays on server farms. I have
virtual machines running Debian unstable with systemd which boot in
less than 4 seconds.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: