Post by firstname.lastname@example.org
2. udev-settle.service serializes the boot process, see attachment
I have feeling that increased parallelism during boot (like starting
fsck/mount as soon as device becomes available) actually has negative
effect on consumer grade devices. My HDD in notebook simply is not
prepared for it ...
ACK. Maybe we should add some intelligence to systemd's automatic
unit-mount creation and serialize partition mounts of the same device?
For traditional systems it's easy, just make all /dev/sda* depend on
each other, but world is bit harder and multiple-device FS like btrfs
or even DM will screw with that. Ideas? Maybe we could do it just
based on /etc/fstab, sorting dependencies based on /dev/sda* and
Post by email@example.com
I tried to create a hotplug.target(which is activated after
default.target), and made udev-settle reside at it, this rendered a
unbootable system. systemd depends on udev at early time.
Thoughts: devtmpfs is mounted, so all cold-plug jobs can be done
without udev involved.
IMHO, fast boot doesn't mean get all services ready in a short time,
but means popup an UI as soon as possible. Windows seems do hotplug
jobs after user log in.
Mandriva uses so called "speedboot" with sysvint - where GUI is
started as soon as possible. It is handcrafted so that only several
device classes are coldplugged and then DM is launched effectively
from rc.sysinit already.
Users did mention that boot under systemd actually feels slower then
Well, I never tried other distro other than Gentoo on this Macbook and
here it's kinda fast at 7s to be 100% ready with E17 (I have an
autostart .desktop that writes to /dev/kmsg to measure it), "Startup
finished in 2s 360ms 651us (kernel) + 1s 753ms 783us (userspace) = 4s
But it could be improved yes. As you all said, maybe we should handle
udev hotplug in a more throttled way by postponing non-critical
devices and having everything else to be hotplug aware? AFAIK Xorg
will handle nicely new input devices. ConnMan/NetworkManager will
handle nicely network devices. Same for bluez. We could even just
activate these services based on the presence of the devices, at least
E17 will handle nicely daemons appearing later by means of DBus
1. should we change ConnMan and NetworkManager to work as BlueZ an
be able to be activated/shutdown by udev hotplug actions (but
cooperative with systemd, bluetoothd is not AFAIR);
2. should we do (or have a way to) force a manual ordering to help
Xorg/DM/WM by avoiding spawn of concurrent services? We know these
have the higher priority, but it's a higher priority only during
startup, later on they should all have the same priority... otherwise
we could just do it by means of systemd's service settings.
A hackish(?) solution would be to have a BootPriority=(True|False),
set to False by default and True for services we care most. Lower
priority services would be set to "background" priority in IO, CPU and
others, then being reset to actual values when systemd is notified.
Problem is we need to notify Systemd of that, as it's not a matter of
just starting "gdm", but actually gdm being in a "usable" state
(defined by gdm itself) or desktop being ready if users use autologin
(like I do). This could also be stated as "system is idle for X
seconds", which would be monitored by systemd itself and then no
manual notification is required.