NO TO SYSVINIT - or initscripts, rather!
NO TO SYSVINIT - or initscripts, rather!
Posted Nov 1, 2018 17:09 UTC (Thu) by flussence (guest, #85566)In reply to: NO TO SYSVINIT - or initscripts, rather! by pizza
Parent article: Init system support in Debian
I just timed power-on to network up with a stopwatch. 13 seconds in the BIOS, 19 more seconds to desktop, 10 seconds more until `ip mon` came to life, so about 42 seconds total. This is on a 9 year old netbook with runit.
Posted Nov 1, 2018 17:45 UTC (Thu)
by mchehab (subscriber, #41156)
[Link] (8 responses)
BIOS/GRUB time a little better... 11 seconds on BIOS, 17 seconds for the first Kernel messages to appear.
However, network comes a lot late here:
1:23 for ping to answer; 1:35 for ssh to log into it.
This machine is a 3 years old NUC (Bios identifies it as NUC5i7RYB) with a 5th gen i7core. It was not supposed to take that 1,5 minutes for ssh do succeed on it. When booting the same machine with Debian and SysV (right now, it is booting Ubuntu/systemd), it takes about 4 times less for ssh to start working.
Posted Nov 1, 2018 18:14 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Be careful, you're not exactly comparing apples to apples here. At the very least, both systems have to be configured to start up the same services before you can make any direct comparison.
Posted Nov 1, 2018 18:47 UTC (Thu)
by seyman (subscriber, #1172)
[Link] (6 responses)
That's certainly a long time. Can you run "systemd-analyse blame"? It might reveal something.
Posted Nov 1, 2018 19:55 UTC (Thu)
by mchehab (subscriber, #41156)
[Link] (5 responses)
26.999s lvm2-monitor.service
The top two things there are not related to network, so shouldn't prevent network to start earlier (it might prevent ssh, though).
The third item (the DNS resolver) took 10 seconds to start, and the only thing to blame would be systemd itself (as it is starting systemd-resolved):
resolvconf.service +10.902s
Anyway, while I'm enjoying this discussion, as it helps me to try optimize booting, we're getting a little OOT here: the point is that systemd seems to be just randomly adding delays to network start for no good reason, and there's no direct way to control it, making network start as early as possible.
In other words, with systemd, the system admin cannot tell it what are the priority services that should be started first.
Posted Nov 2, 2018 0:25 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (1 responses)
In a nutshell, systemd is a developer's boot stamping on the face of a sysadmin/syseng... begging the question with their design choices on so many paradigm shifts that the administrator gives up trying to fight it, and eventually gives up trying to grok it at all.
Posted Nov 2, 2018 19:24 UTC (Fri)
by naptastic (guest, #60139)
[Link]
You've hit the nail on the head. However much of systemd is NIH syndrome, or enforcing vendor lock-in, or adding complexity so people will pay for support, or just obliviousness to reality, systemd is just... well, I remove it as fast as I can wherever I can, and every time I do, life gets better. My systems boot faster, shut down faster, have fewer random problems, and are easier to troubleshoot.
Posted Nov 2, 2018 0:45 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
I wonder if you have an unrelated issue in your systems somewhere.
Posted Nov 2, 2018 1:32 UTC (Fri)
by zlynx (guest, #2285)
[Link]
There is definitely something wrong. If it's reading from an M.2 drive benchmark that thing, because it's looking broken.
I believe my last NAS with dual Bobcat cores at 1.6 GHz booted faster than that.
I think Raspberry Pi's reading from slow sdcards are quicker.
Posted Nov 2, 2018 19:11 UTC (Fri)
by mchehab (subscriber, #41156)
[Link]
Yeah, there was indeed an issue: I build kernels with KASAN enabled. That, together with all stuff systemd tries to load and then unload at the initrd disk, made it really slow (it was spending ~30 seconds at initrd). I did a clean custom.target with the minimum stuff, with improved it a lot:
$ ls /etc/systemd/system/custom.target.wants/
Also removed an open-iscsi package (with alone saved almost 15 seconds).
After lots of cleanups, I was able to reduce the time for network to start to "just" 1 minute, with KASAN enabled.
Without KASAN, using a vanilla Ubuntu Kernel, it is now booting really quick:
Startup finished in 777ms (kernel) + 2.416s (initrd) + 8.385s (userspace) = 11.579s
Discovering it costed me an entire day of work. Doing the same with sysV would be trivial.
NO TO SYSVINIT - or initscripts, rather!
NO TO SYSVINIT - or initscripts, rather!
NO TO SYSVINIT - or initscripts, rather!
NO TO SYSVINIT - or initscripts, rather!
25.765s dev-mapper-localhost\x2d\x2dvg\x2dubuntu.device
10.902s resolvconf.service
9.526s keyboard-setup.service
9.497s systemd-modules-load.service
8.397s kmod-static-nodes.service
8.387s systemd-remount-fs.service
8.067s binfmt-support.service
7.825s sys-kernel-debug.mount
...
└─systemd-journald.socket
└─system.slice
└─-.slice
NO TO SYSVINIT - or initscripts, rather!
NO TO SYSTEMD
NO TO SYSVINIT - or initscripts, rather!
You can whack it with a hammer and delete the dependencies of the network service. But your startup times look really unhealthy anyway, 10 seconds for resolvd is unbelievable.
NO TO SYSVINIT - or initscripts, rather!
NO TO SYSVINIT - or initscripts, rather!
anacron.service dbus.service networking.service rsyslog.service systemd-resolved.service thermald.service atd.service inetd.service NetworkManager.service ssh.service systemd-update-utmp-runlevel.service ttyUSB0.service cron.service irqbalance.service ondemand.service systemd-logind.service systemd-user-sessions.service
custom.target reached after 8.383s in userspace