Devuan 1.0 Makes It To A Release Candidate: Debian Without Systemd

[caligula]

Considering my xubuntu install went from booting in 20-30s to now with systemd taking almost 2 mins I hope this does well...

Ok, so did you use the systemd analyze tools to locate the source of this delay? My 8 year old AMD system (Gentoo + Systemd) boots in 8 seconds (kernel + init). It has 3 disks (root is ssd) and sets up 3 network interfaces, including wireless AP. The SSD admittedly has a large effect on boot time, but I bought an old used 60 GB drive which only goes up to 250 MB/s. You can find drives twice as fast for $30.

[float]

Why does everyone keeps talking about shell-scripts on the topic of sysvinit? You can use any file accepted by exec* and posix_spawn* functions to my knowledge, which usually means any file with a #! and elfs.

I am pretty sure that nothing would stop you from using a systemd init file with sysvinit if it had the correct #!.

[starshipeleven]

Why does everyone keeps talking about shell-scripts on the topic of sysvinit?

Because that's what is used with sysvinit in distros that still ship it, duh.

You can use any file accepted by exec* and posix_spawn* functions to my knowledge, which usually means any file with a #! and elfs.

Most distros use(d) shell scripts because it's faster to parse a relatively limited shell like ash/dash/whatever than firing up Perl, Bash or whatever.

Elfs are against the whole point most that makes people prefer scripts in an init (i.e. being able to see what is being done and change it easily), and afaik no distro EVER used them directly.

Devuan is just keeping alive old Debian way of using sysvinit so that's shell scripts.

I am pretty sure that nothing would stop you from using a systemd init file with sysvinit if it had the correct #!.

??? Systemd uses text config files. Sure it has a fallback that allows it to run sysvinit scripts, but how can you get sysvinit to run something like this?

[Unit]
Description=Simple DBus service  

[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service  

[Install]
WantedBy=multi-user.target

[starshipeleven]

Ok, so did you use the systemd analyze tools to locate the source of this delay?

Systemd should not need that. Even if distro mantainers ship bullshit applications still using initscripts that take ages to start up systemd will magically start them up in seconds even if it has no way of knowing what is happening there.

Because Pottering is awesome.

/sarcasm

[caligula]

Try it I know one use case where Devuan is faster than systemdfied Jessie, that is 32bit instalation.

Systemd is somewhat slow on 32bit Jessie, probably no one care about these anymore... but nope, Devuan one sysv boot is normal fast there

Can't claim totally, but i can conclude that systemd seems shit on some arches - it might be good only if you match exactly what Poettering is using

Can you show your $ systemd-analyze blame ?

[caligula]

Systemd should not need that. Even if distro mantainers ship bullshit applications still using initscripts that take ages to start up systemd will magically start them up in seconds.

Because Pottering is awesome.

/sarcasm

It sure can start them up quickly if it can fork them in the background and the critical path to launching desktop doesn't depend on them. But the same is true for any init system.

But I'm a bit puzzled, what could cause these sort of delays? I've run systemd on RPi 1 (700 Mhz ARMv6), first gen Atom, Pentium III, Athlon XP, damn slow old VPS. They all start rather quickly even from class 4 SD cards (Raspberry). TBH I always use some sort of solid state media for root fs so the random access IOPS numbers are pretty good. Why - 16GB SATA2 SSD 200+ MB/s drive for storing the OS is less than $20 now. 64GB is $30 for that matter. There is no excuse for not buying one.

Sure, traditional hard drives would benefit from prefetch, but systemd parallelizes loading, which is always faster than 100% sequential old style sysvinit. BSDs are especially slow. For instance one FreeNAS box I set up used to boot for 2.5 minutes from HDD. Standard installation, not even initializing any volumes, just booting the web middleware. I switched to USB2 based linux live OS (systemd + debian) and the boot time reduced to 10 seconds (after BIOS POST tests), including btrfs start up. Soo.. lots of incompetence or bad luck gathering around here.

[Helios747]

Considering my xubuntu install went from booting in 20-30s to now with systemd taking almost 2 mins I hope this does well...

Sounds like a blocking job hung.

On arch I noticed that will happen if I incorrectly configured DHCP or something.

[starshipeleven]

It sure can start them up quickly if it can fork them in the background and the critical path to launching desktop doesn't depend on them.

This happens if the service has a proper systemd unit so it knows enough to take the decision. If the only thing it has is a crappy initscript loaded in compatibility mode, it has to go sequential as it does not know enough to decide if forking it is good or not.

So you can get that boot is blocked or slowed down considerably by stuff that if configured correctly would be forked in the background while boot proceeds.

But I'm a bit puzzled, what could cause these sort of delays?

Apart from the initscrpt in fallback mode as said above, it's misconfigured critical services that are set to block boot until they are done. Systemd decides what to do by reading what is written in the service's config after all.

The most common I've seen is some totally retarded dhcp client that blocks boot and waits like a full minute to get a lease on a disconnected ethernet cable (while NetworkManager realizes that there is no connection after a few seconds). Both on Debian and OpenSUSE.
I mean it might be cool for a server where you NEED eth to be connected, but not on a desktop where you 99% want NetworkManager.

I've run systemd on RPi 1 (700 Mhz ARMv6), first gen Atom, Pentium III, Athlon XP, damn slow old VPS. They all start rather quickly

Same here, on a Kirkwood (single ARMv6 core clocked at 1.6 Ghz) NAS booting a headless Debian from a sata partition in the drives it's all done in like 10 seconds (excluding bootloader's wait and working time). That's basically a server build though.

On my main system it's a bit slower as there is a full GUI but it still shows login screen in less than a minute. (I'm using HDDs and a btrfs RAID1 because I don't really care about super-fast boot)

BSDs are especially slow. For instance one FreeNAS box I set up used to boot for 2.5 minutes from HDD. Standard installation, not even initializing any volumes, just booting the web middleware. I switched to USB2 based linux live OS (systemd + debian) and the boot time reduced to 10 seconds (after BIOS POST tests), including btrfs start up.

Heh, most BSDs use sysvinit because it's more Unix or something.

Less-dumb BSDs like TruOS use Gentoo's init, OpenRC, also called "what Upstart was supposed to become".
It is still script-based but is at least modern and can multithread properly the startup among other things.

Staying on sysvinit and calling it "init freedom" is one of the things that made me say Devuan is a very stupid choice.
Give it OpenRC at least, damnit.

[starshipeleven]

Sounds like a blocking job hung.

On arch I noticed that will happen if I incorrectly configured DHCP or something.

Aha! That dhcp client I talked in my post above is an annoyance also on Arch.

[Guest]

This is stupid

Sadly some will still be weeping their distribution switched to systemd decades from now instead of doing something useful such as reporting systemd bugs.