Debian Boot Sequence [Withdrawn]

[llewellen]

This is intended as a serious, I would like to know, question and not as a criticism or snide remark.

Why is the Debian boot sequence quite noticeably clunkier, cluttered and much slower than some others like, for example, Manjaro?

[tynman]

You may intend your question to sound serious, but you failed... it sounds like trolling to me. Obviously, I shouldn't take the bait...

I can't begin to imagine what a "clunkier, cluttered" boot sequence would refer to or what it would look like. And I doubt it is something anyone could quantify or measure.

As for boot up speed, my Debian Stretch system boots to the login prompt in just under 8 seconds. I haven't made any attempt to trim away unused services that might be making the boot up longer than necessary. After I login, my X11 "desktop" initializes in under 5 seconds. From where I sit, that's fast, so I haven't bothered to look into how to make it boot up faster. Even if there are other Linux distributions that boot up to a login prompt in half that time (under 4 seconds?), I don't think I would find that feature a motivation to entertain switching to the "faster booting" distribution.

[llewellen]

You may intend your question to sound serious, but you failed... it sounds like trolling to me. Obviously, I shouldn't take the bait...

I can't begin to imagine what a "clunkier, cluttered" boot sequence would refer to or what it would look like. And I doubt it is something anyone could quantify or measure.

As for boot up speed, my Debian Stretch system boots to the login prompt in just under 8 seconds. I haven't made any attempt to trim away unused services that might be making the boot up longer than necessary. After I login, my X11 "desktop" initializes in under 5 seconds. From where I sit, that's fast, so I haven't bothered to look into how to make it boot up faster. Even if there are other Linux distributions that boot up to a login prompt in half that time (under 4 seconds?), I don't think I would find that feature a motivation to entertain switching to the "faster booting" distribution.

I invite you to withdraw your accusation of trolling. Iasked a serious question sincerely. I would like to know what accounts for the obvious difference.

[Head_on_a_Stick]

I find that Debian boots slightly faster than Arch but only after disabling the half-million[1] superfluous unit files that Debian insists on enabling OOTB, I even have to do a regular check and disable any rogue units that have been brought in by package installations and auto-enabled, it's a bit annoying tbh.

[1] Exaggerated for comic effect.

[None1975]

Guys, no need to feed the troll. Somewhere in this forum, I already wrote that my system was loading in nine seconds (system on hdd).

[ticojohn]

I find Debian boot times to be pretty fast. I would think that if the OP was really serious with the question he/she would post something definitive showing how, in their opinion, Debian is slow and clunky. On my PC, I go from cold start to the login prompt (lightdm) in about 10 seconds, and that includes about 4 seconds for the bios and 5 seconds for the GRUB screen timeout. I do have a SSD on SATA3, so that speeds things up considerably. And on my Intel NUC, used for home theater, it's even faster. The NUC has a 4x m.2 SSD on PCIE. It's smoking fast at startup.

[llewellen]

I had no intention of touching upon an exposed nerve of defensiveness. The question is withdrawn.

[Head_on_a_Stick]

Fresh stretch system:

Code: Select all

empty@hegel:~ $ systemd-analyze                                                      
Startup finished in 2.790s (kernel) + 1.684s (userspace) = 4.475s
empty@hegel:~ $

Seems pretty quick to me

I have quiet set so I see nothing during the boot process until the TTY prompt appears (promptly).

What exactly do you mean by "cluttered"?

I have no failed units:

Code: Select all

empty@hegel:~ $ systemctl --failed
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
empty@hegel:~ $

I won't bore you with the journal contents but they look pretty "clean" to me, only a few inconsequential (and useful) warnings; no errors at all that I can see.

[llewellen]

@Head_on_a_Stick: Thank you for the substantive response. At the risk of inviting further flame throwers:

I'm running Debian-Testing on an ASUS X200CA (my backup experimenting laptop)

Code: Select all

 drew@dell:~$ systemd-analyze
Startup finished in 4.719s (firmware) + 5.820s (loader) + 4.527s (kernel) + 54.908s (userspace) = 1min 9.976s
graphical.target reached after 28.506s in userspace
drew@dell:~$ 
 

[Head_on_a_Stick]

At the risk of inviting further flame throwers

Pro Tip: ignore fuckwits.

Code: Select all

54.908s (userspace)

That ain't right, please post

Code: Select all

systemd-analyze blame
systemd-analyze critical-chain

You could even try

Code: Select all

systemd-analyze plot > boot.svg

but I could never make much sense of that graph...

[llewellen]

@Head_on_a_Stick:

Code: Select all

  drew@dell:~$ systemd-analyze blame
         30.993s apt-daily.service
          7.968s udisks2.service
          7.661s ModemManager.service
          7.576s NetworkManager.service
          6.975s networking.service
          6.819s accounts-daemon.service
          6.258s speech-dispatcher.service
          5.886s wpa_supplicant.service
          5.818s systemd-logind.service
          5.817s switcheroo-control.service
          5.812s rsyslog.service
          5.440s avahi-daemon.service
          5.365s pppd-dns.service
          5.085s exim4.service
          4.687s dev-sda2.device
          3.886s NetworkManager-wait-online.service
          1.651s systemd-rfkill.service
          1.235s keyboard-setup.service
          1.000s systemd-fsck@dev-disk-by\x2duuid-AACD\x2dAB72.service
           925ms upower.service
           893ms packagekit.service
           878ms console-setup.service
           845ms gdm.service
           793ms user@115.service
           740ms dev-disk-by\x2duuid-6be67239\x2d5498\x2d4c44\x2d9866\x2da856e0e
           686ms systemd-udevd.service
           685ms systemd-modules-load.service
           644ms boot-efi.mount
           640ms systemd-tmpfiles-setup.service
           560ms systemd-journald.service
           495ms systemd-sysctl.service
           486ms apt-daily-upgrade.service
           479ms polkit.service
           462ms systemd-sysusers.service
           450ms systemd-tmpfiles-setup-dev.service
           435ms colord.service
           412ms systemd-backlight@backlight:intel_backlight.service
           399ms dev-hugepages.mount
           393ms systemd-timesyncd.service
           347ms sys-kernel-debug.mount
           339ms systemd-remount-fs.service
           333ms systemd-update-utmp.service
           309ms systemd-random-seed.service
           306ms systemd-journal-flush.service
           300ms dev-mqueue.mount
           288ms systemd-udev-trigger.service
           220ms bolt.service
           117ms user@1000.service
            74ms systemd-user-sessions.service
            64ms systemd-tmpfiles-clean.service
            59ms kmod-static-nodes.service
            44ms rtkit-daemon.service
            13ms alsa-restore.service
            10ms systemd-update-utmp-runlevel.service
lines 32-54/54 (END)

This hung up and did not return to the terminal prompt/cursor

Code: Select all

 drew@dell:~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @28.506s
└─multi-user.target @28.506s
  └─exim4.service @23.420s +5.085s
    └─network-online.target @23.417s
      └─NetworkManager-wait-online.service @19.530s +3.886s
        └─NetworkManager.service @11.952s +7.576s
          └─dbus.service @11.943s
            └─basic.target @11.924s
              └─sockets.target @11.924s
                └─avahi-daemon.socket @11.924s
                  └─sysinit.target @11.866s
                    └─systemd-timesyncd.service @11.472s +393ms
                      └─systemd-tmpfiles-setup.service @10.782s +640ms
                        └─local-fs.target @10.652s
                          └─run-user-115.mount @22.069s
                            └─swap.target @9.684s
                              └─dev-disk-by\x2duuid-6be67239\x2d5498\x2d4c44\x2d
                                └─dev-disk-by\x2duuid-6be67239\x2d5498\x2d4c44\x
lines 1-21/21 (END)
 

Also hung up in terminal without returning to the input prompt.

systemd-analyze plot > boot.svg did nothing. Just returned to the terminal input prompt.

[Head_on_a_Stick]

This hung up and did not return to the terminal prompt/cursor
[...]
Also hung up in terminal without returning to the input prompt.
[...]
systemd-analyze plot > boot.svg did nothing. Just returned to the terminal input prompt.

The `systemd-analyze {blame,critical-chain}` commads are run through a pager so that you can scroll up & down and side to side ("q" will quit the pager), if that bothers you try this instead:

Code: Select all

systemd-analyze blame --no-pager

And as for the plot, try

Code: Select all

inkscape boot.svg

and behold the glory...

Anyway, it looks like apt-daily.service is holding things up so investigate some more:

Code: Select all

systemctl cat apt-daily --no-pager # what does it do?
# journalctl -u apt-daily --no-pager # what's going wrong? (May be easier with the pager)

Or just kill it regardless:

Code: Select all

# systemctl disable apt-daily

[llewellen]

@Head_on_a_Stick: What is apt-daily.service?

Code: Select all

 drew@dell:~$ systemctl cat apt-daily --no-pager
# /lib/systemd/system/apt-daily.service
[Unit]
Description=Daily apt download activities
Documentation=man:apt(8)
ConditionACPower=true
After=network.target network-online.target systemd-networkd.service NetworkManager.service connman.service

[Service]
Type=oneshot
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

drew@dell:~$ 
 

Code: Select all

  drew@dell:~$ su
Password: 
root@dell:/home/drew# journalctl -u apt-daily --no-pager
-- Logs begin at Sun 2018-05-27 06:59:54 PDT, end at Sun 2018-05-27 09:45:01 PDT. --
May 27 07:00:13 dell systemd[1]: Starting Daily apt download activities...
May 27 07:00:43 dell systemd[1]: Started Daily apt download activities.
root@dell:/home/drew# exit
exit
drew@dell:~$ 

[llewellen]

@Stick_on_a_Head: I found this on Ask Ubuntu:

"This is Debian bug #844453. apt-daily.service shouldn't be run during boot, but only some time afterward.

As a workaround, do sudo systemctl edit apt-daily.timer and paste the following text into the editor window:

# apt-daily timer configuration override
[Timer]
OnBootSec=15min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=30min
This changes the "timer" that triggers apt-daily.service to run at a random time between 15 min and 45 min after boot, and once a day thereafter."

What say you?

[Head_on_a_Stick]

What say you?

Does apt-daily.service actually delay your desktop startup time?

As observed in the bug report, the time reported by `systemd-analyze` does *not* represent the time taken to achieve a usable desktop but rather indicates when all of the startup processes have finished.

Have you timed how long it takes for your box to show a login prompt with a stopwatch and compared it with the command output'?

[llewellen]

Does apt-daily.service actually delay your desktop startup time?

As observed in the bug report, the time reported by `systemd-analyze` does *not* represent the time taken to achieve a usable desktop but rather indicates when all of the startup processes have finished.

Have you timed how long it takes for your box to show a login prompt with a stopwatch and compared it with the command output'?

Power on to login window = 70 seconds. Almost identical to what the command produced.

[Head_on_a_Stick]

^ Disable it then:

Code: Select all

# systemctl disable apt-daily{,-upgrade}.timer

It just runs `apt update` every day, see /usr/lib/apt/apt.systemd.daily for the gory details.

[llewellen]

Yes but as my previous quote from Ask Ubuntu said, perhaps it shouldn't be doing that during boot. The scripit that was proposed there would delay it running until after the boot finished. Do you agree with that approach or should I just kill it altogether since I do run apt update apt upgrade manually everyday anyway.

[llewellen]

Sorry, I just re-read you post and you advise to disable it. That's what I will do.

[llewellen]

I ran # systemctl disable apt-daily #but the boot still takes 65 seconds.

It's hanging up at a line:

/dev/sda2 : clean, 179382/30236672 files 3866965/120945920 blocks

???