NixOS 18.09 slow boot issues

Development
1

Logging in to Plasma5 is extremely slow (20 seconds on a recent USD 2K+ laptop) after I press enter.

I think nobody actually did any optimization to make life better for NixOS users (not developers). I.e. it would be possible for the entire Plasma5 system to be loaded from a single file and loaded into RAM. This way, starting Plasma5 should be able to run within less than one second. Since I don’t login often, I have accepted this, but it’s not normal.

If one is talking about modern operating systems, one would expect that the default install has received some optimization to meet basic requirements. I am pretty sure that “time to working desktop” is a metric being used within Microsoft.

1 Like
2

Bootup time is definitely something we can improve. It would be interesting to see the output of systemd-analyze blame and systemd-analyze critical-chain. There could just be some service really slowing things down.

2 Likes
3

Something seems to be wrong with docker.

These are the top ones.

2min 37.802s docker.service
6.127s dhcpcd.service
2.477s dev-disk-by\x2duuid-

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 @2min 50.440s
└─multi-user.target @2min 50.440s
  └─docker.service @12.637s +2min 37.802s
    └─network-online.target @12.636s
      └─network.target @12.629s
        └─dhcpcd.service @6.501s +6.127s
          └─basic.target @6.499s
            └─sockets.target @6.499s
              └─docker.socket @6.498s +1ms
                └─sysinit.target @6.427s
                  └─systemd-udev-settle.service @1.323s +5.104s
                    └─systemd-udev-trigger.service @1.184s +136ms
                      └─systemd-udevd-control.socket @1.184s
                        └─-.mount @1.173s
                          └─system.slice @1.173s
                            └─-.slice @1.173s

docker ps -a returns no recently started images.

4 
graphical.target @5.605s
└─multi-user.target @5.605s
  └─docker.service @2.928s +2.676s
    └─network-online.target @2.927s
      └─network.target @2.904s
        └─wpa_supplicant.service @4.629s +21ms
          └─basic.target @2.609s
            └─sockets.target @2.609s
              └─docker.socket @2.608s +1ms
                └─sysinit.target @2.604s
                  └─systemd-udev-settle.service @379ms +2.224s
                    └─systemd-udev-trigger.service @319ms +58ms
                      └─systemd-journald.socket @318ms
                        └─system.slice @313ms
                          └─-.slice @313ms

Similar over here. Docker probably doesn’t need to block the multi-user target.

5

Does docker consistently take this long to start for you? I remember docker taking ages to start after an update due to migrating the on-disk image format or something like that, and it would take that long on every start until I just left it to do its fiddling for half an hour or something.

6

Unknown. I rarely reboot.

I do see:

failed to retrieve docker-runc version: unknown output format: runc version 1.0.0-rc5+dev\nspec: 1.0.0\n"

level=warning msg="Could not register builder git source: failed to find git binary: exec: \"git\": executable file not found in $PATH"

I expect to see zero such warnings when running systemctl status docker after a sequence of operations that are only configuration changes in configuration.nix via documented interfaces.

7

Adding virtualisation.docker.enableOnBoot = false; should remove docker from the boot chain.

1 Like
8

I don’t want to remove it from the boot chain; I want it to start in a reasonable amount of time.