0

I set up a Raspbian stretch lite and am about to make it start xserver after boot. Now I am confused about the long boot time! I ran system-analyze blame to check which services take the most time: 

22.489s dev-mmcblk0p2.device
19.172s systemd-fsck-root.service
14.558s networking.service
 5.648s hciuart.service
 2.821s keyboard-setup.service
 2.750s systemd-rfkill.service
 2.706s dphys-swapfile.service
 2.403s raspi-config.service
 1.971s systemd-logind.service
 1.277s systemd-journald.service
 1.172s systemd-udev-trigger.service
  889ms systemd-udevd.service
  746ms systemd-modules-load.service
  733ms systemd-timesyncd.service
  658ms avahi-daemon.service
  656ms systemd-tmpfiles-setup.service
  647ms sys-kernel-debug.mount

Now I'm asking myself, which of those services could I manually start after boot? I guess the first two init the root file system, but could I optimize them somehow? As ~40secs are much time!
In my case, networking and avahi can also be called later, but how can I remove them from systemd and start manually after boot? I actually need uart before boot finished, so hciuart and udev are not an option. So the basic questions are:
What services are really needed?
Are there any init scripts running besides systemd? How can I find out? How can I remove them from systemd?
How can I start them manually? (after boot is finished and my xserver is running)
In Raspbian Jessie I already used the ~/.configs/lxsessions/autostart to start applications after boot, but in stretch lite there is no such file, besides I'm not using lxde anymore, just xorg and openbox (and the autostart file I created in ~/.configs/openbox/autostart doesn't do anything)

PPS: output of systemd-analyze time:
Startup finished in 1.709s (kernel) + 39.832s (userspace) = 41.541s
and critical-chain output: 

multi-user.target @39.667s  
└─getty.target @39.661s  
  └─autologin@tty1.service @39.652s  
    └─rc-local.service @39.108s +158ms  
      └─network.target @39.023s  
        └─networking.service @24.439s +14.558s  
          └─local-fs.target @24.293s  
            └─boot.mount @24.077s +195ms  
              └─systemd-fsck@dev-disk-by\x2dpartuuid-3935b193\x2d01.service @23.518s +542ms  
                └─dev-disk-by\x2dpartuuid-3935b193\x2d01.device @23.495s
Marcel H.
  • 11
  • 4
  • 1
    That fsck takes so long implies it is actually running -- which it only does for one of two reasons: 1) It reaches the "maximum mount count" set on the filesystem (you can find this with tune2fs /dev/mmcblk0p1 | grep -i "mount count" although it is probably -1, indicating there is no maximum); 2) The filesystem was considered "dirty", usually a result of not shutting the system down "cleanly" (e.g., via halt or shutdown). This is a precaution necessary to mitigating the risk of filesystem corruption when you pull the plug, so if you want to save yourself some time at boot, don't. – goldilocks Feb 15 '18 at 14:25
  • I realize the duplicate is not exact, but it should answer some or most of your questions here such that if you need to, you can ask something more specific. "As ~40secs are much time!" -> The times are not necessarily cumulative as these events may run in parallel (on a multicore pi), although since fsck is I believe a dependency for some critical things, it will slow everything down noticeably when it actually needs to evaluate the disk. – goldilocks Feb 15 '18 at 14:30
  • Nevermind, I will post another question according to systemd if necessary, but you already helped a lot with the hint to using halt rather than poweroff, the mmcblk0p2 is down to 6sec and the fsck task is even below 1sec :) thanks also for the correction about the times, I forgot about that they run in parallel (I even think it's also running parallel on a single core pi) – Marcel H. Feb 15 '18 at 15:10
  • They do run in parallel on a single core too, just in that case the times will be cumulative (although I'm still not sure if the time from systemd-anaylyze blame is a total for the service, or the time on a common clock the initialization completed at). – goldilocks Feb 15 '18 at 15:49

0 Answers0