• Unusual slow boot


    Hello, I got unusual slow antergos KDE boot it is near 2 min, before several weeks it was about 30-40s. Using HDD, btrfs. When booted programs starts quite fast, for example chromium with many tabs in 6s, qt creator in 7s.
    Any ideas why this could be?

         42.834s lightdm.service
         27.292s NetworkManager.service
         26.304s logrotate.service
         15.063s dev-sda6.device
         10.052s systemd-udevd.service
          9.711s systemd-journal-flush.service
          1.915s boot-efi.mount
          1.663s systemd-modules-load.service
          1.620s systemd-remount-fs.service
          1.353s systemd-logind.service
          1.025s udisks2.service
  • can you provide logs please?

    https://antergos.com/wiki/miscellaneous/how-do-i-include-system-logs-when-asking-for-help/

    seems to be related to problem with lightdm

  • systemd-analyze blame and systemd-analyze plot shows that every day different services cause slow boot, it is strange because when booted to desktop, programs starts not slower than before. But boot often takes ~2 min (vs ~35 s before).
    I installed Xilinx ISE (fpga development environment) which contains about 300000 files, but there is more than 50% of free space in HDD.

    For example last boot (about 1 min 55 s till desktop):

         31.279s logrotate.service
         17.302s dev-sda6.device
         16.684s systemd-journal-flush.service
          2.315s NetworkManager.service
          2.311s systemd-logind.service
          2.038s systemd-udevd.service
          1.520s boot-efi.mount
          1.228s udisks2.service
    

    journalctl -u logrotate.service -b shows only:
    Nov 07 18:17:38 pc systemd[1]: Starting Rotate log files…
    Nov 07 18:18:10 pc systemd[1]: Started Rotate log files.

    journalctl -u dev-sda6.device -b shows no logs:
    – No entries –

    journalctl -u systemd-journal-flush.service -b
    Nov 07 18:17:19 pc systemd[1]: Starting Flush Journal to Persistent Storage…
    Nov 07 18:17:36 pc systemd[1]: Started Flush Journal to Persistent Storage.

  • @Kestutis boot logs would be more interesting… as services seem to start …

    journalctl -b -0
    
  • here it is https://pastebin.com/1BKATMPa
    last boot:

         59.459s lightdm.service
         21.275s dev-sda6.device
         11.617s NetworkManager.service
         10.281s logrotate.service
          4.585s dev-sda5.swap
  • Is there any disk file indexing program running?
    Those lately installed 300000 files may be the cause. Can you move them to a new partition (and mount that)?

    Also, SSD could be a great solution. :)

  • I disabled baloo indexer, and made “updatedb” and “man-db” timers run on only 15 min after boot.

    Also I removed Xilinx ISE (which contained 300000 files) and some other programs, now there are only CUDA toolkit, Qt Creator, and few Python libs installed by me.

    I tried to do btrfs filesystem defrag, but filesystem was not much fragmented.
    Programs, when booted up to desktop, launches quite fast. At my use case it’s not so big issue to buy SSD. So slower boot seems not to be caused by fragmentation.
    I am thinking what else could be cause?

    Last boot I saw: “update journal catalog” and “rebuild dynamic liker cache” processes took much of 1 min 35 s boot time. This time lightdm service took much less time:

         41.254s ldconfig.service
         13.242s systemd-journal-catalog-update.service
          8.827s boot-efi.mount
          5.850s dev-sda6.device
          5.582s dev-sda5.swap
          3.459s systemd-journal-flush.service
          2.531s systemd-timesyncd.service
          1.471s systemd-tmpfiles-setup.service
          1.407s systemd-udevd.service
          1.315s NetworkManager.service
          1.132s lightdm.service
          1.130s systemd-logind.service
    

    update: when I boot next time today lightdm took 38.586s lightdm.service
    here is lightdm log: https://pastebin.com/xruNScPi

boot271 slow31 unusual1 Posts 7Views 173
Bloom Email Optin Plugin

Looks like your connection to Antergos Community Forum was lost, please wait while we try to reconnect.