Clear Linux starts up much more slowly after Gnome 3.36
Earlier, it started up about 4 seconds after user login. Now I see a blank screen for about 20 seconds before the startup is complete. Guess it’s due to the Gnome update? The fact that Clear Linux “changes” are behind such a large change in time I doubt. Are more people experiencing longer start-up times? Is there anything to do about this? The only change I have made is to replace the wallpaper.
I haven’t noticed any delay after the upgrade of Gnome to 3.36.
Run
systemd-analyze
Startup finished in 9.503s (firmware) + 309ms (loader) + 7.341s (kernel) + 1.809s (userspace) = 18.964s
graphical.target reached after 1.606s in userspace
The time is so big because I have disk encryption + user login password.
Also check systemd-analyze --help in particular
systemd-analyze blame
This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output
might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete.
HTH,
Takov
Have you installed proprietary Nvidia driver?
There was an report that GDM didn’t correctly disable Wayland with NVIDIA driver, and manually disable it solved the problem of long boot times.
Tested with systemd analysis. A new command for me. There is apparently a lot to learn.
Results below.
Regarding “graphical.target reached after 22.094s in userspace”, is this the time I mention as the time after logging in as a user? I’ve only appreciated that time before.
Nothing here that points to any specific cause, right?
systemd analysis [time] Print time required to boot the machine
Startup finished in 2,249s (firmware) + 312ms (loader) + 10,633s (kernel) + 22,094s (userspace) = 35,290s
graphical.target reached after 22,094s in userspace
systemd analysis critical-chain [UNIT …] Print a tree of the time critical chain of units
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 22.094s
└─multi-user.target @ 22.094s
└─sav-protect.service @ 1.354s + 20.739s
└─basic.target @ 1.293s
└─sockets.target @ 1.293s
└─uuidd.socket @ 1.293s
└─sysinit.target @ 1.283s
└─systemd-timesyncd.service @ 1.283s
└─systemd-tmpfiles-setup.service @ 1.234s + 43ms
└─local-fs.target @ 1.225s
└─run-user-1000-gvfs.mount @ 17.450s
└─run-user-1000.mount @ 16.639s
Wapswap.target @ 1.219s
└─dev-sda2.swap @ 1,200s + 17ms
└─dev-sda2.device @ 1.193s
Did you install Sophos Anti-Virus for Linux ?
See the second service: sav-protect.service.
Same problem was discussed here:
HTH
1 Like
I installed Sophos from day 1. So it was also installed earlier when the boot time was on low about 4 seconds. That time for Sophos is individual and goes in parallel, so the system does not wait for that service? Considering earlier about 4 seconds startup shouldn’t that be the “problem”?
How know 
You can log a bug and the dev team will help you: Report a Bug | Clear Linux* Project
However just for the sake of the test you can try to temporary disable sophos and see what is the results. Most probably this will be the first think they will ask you.
What does “systemd-analayze blame” says ? Does it show different result.
Test with “systemd-analysis blame” shows on 13st services a time span of 4 thousand seconds!
Test again with the following command
systemd analysis critical-chain
graphical.target @ 22.265s
└─multi-user.target @ 22.264s
└─sav-protect.service @ 1.414s + 20.849s
└─basic.target @ 1.379s
└─sockets.target @ 1.377s
└─uuidd.socket @ 1.376s
└─sysinit.target @ 1.363s
└─systemd-timesyncd.service @ 1.363s
└─systemd-tmpfiles-setup.service @ 1.304s + 53ms
└─local-fs.target @ 1,299s
└─home-computer-TresoritDrive.mount @ 21.415s
└─local-fs-pre.target @ 186ms
Dsystemd-remount-fs.service @ 177ms + 8ms
└─systemd-journald.socket @ 168ms
└─-.mount @ 97ms
└─system.slice @ 97ms
└─-.slice @ 97ms
There the following appeared which did not appear yesterday. I have autostart on this service.
home-computer-TresoritDrive.mount @ 21.415s
Tried to stop Sophos service with the following command.
First a check.
systemctl list units | grip saw
sav-protect.service loaded active running “Sophos Anti-Virus daemon”
Stopping service.
systemctl stop sav-protect.service
Restarted, but with “systemctl list-units | grep sav” I got the same response after restart as before = “running”, so that command apparently only turned off the service temporarily.
However, there were additional commands at 19.04 - Very slow boot time and poor perfomance - Ask Ubuntu (pasted below).
which is supposed to permanently turn off the service, but I did not test this. When again no change is made between the two version changes. I Think that then something else should be behind, but of course, you never know.
"If virus scan at boot-time and on-access is not critical to your system, you can disable the service and gain back speed at boot-time and system responsiveness. To do this, please run the following command in the terminal and reboot your system:
sudo systemctl disable sav-protect.service
If it shows up again after reboot, you can follow the above command with this:
sudo systemctl mask sav-protect.service
If you get alerts at boot-time about real-time protection being disabled, you can follow the above commands with this:
sudo systemctl disable sav-rms.service
If it shows
up again after reboot, you can follow the above command with this:
sudo systemctl mask sav-rms.service
To roll back the above changes anytime, please run:
sudo systemctl unmask sav-protect.service
Then follow it with this:
sudo systemctl enable sav-protect.service
Then follow it with this:
sudo systemctl unmask sav-rms.service
Then follow it with this:
sudo systemctl enable sav-rms.service
Notice:
All of the above is done without the need to uninstall Sophos Anti-Virus for Linux. It will remain on your system so you can use other features of the Anti-Virus or you can later roll back the changes done above and go back to the full blown package as you wish. "
I do not want to create a case for this. Then they seem to be full, and the problem in my case is something I can live with. But being thoughtful about, as I do not think the program changes should render in this deviation.
hm, thoughtful
systemctl stop just stop a service.
You have to use systemctl disable
… and i would suggest - if “antivir” on linux is really necessary for you - only clamav (not the clamtk-flatpak, the clamav-bundle).
Absolutely. Can you elaborate on why Clamav would be preferable to Sophos.
Do you mean that Sophos would affect in this extent now after the upgrade, since it has had no impact on startup time in the past? Isn’t Sophos running parallel to startup? And therefore does not add time to this. Can’t it have anything to do with the change, the upgrade of Gnome. Or am I unique with the installation of Sophos and for that reason no one else is affected by slower startup time? Not easy this.
I suggest you to temporarily disable Sophos to see whether that does shorten boot times.
Only then we can investigate why it’s slow.
TresoritDrive.mount is indeed new thing 
You can try to disable it as well and see what the result is.
I would recommend you to do a couple of restarts and do “systemd analysis critical-chain” after each restart to see if the results are constant.
Also if there are other third-party softwares that are auto-started with the OS you can disable them. I am talking about software that are manually installed. The idea is to make Clear Linux as clean as possible. This would help troubleshooting the problem.
I have now closed Sophos and Tresorit. It was strange that after turning off Sophos it shows that it is still active when testing with systemctl list units | grip saw. But after restarting, it has disappeared during tests with systemd-analysis critical-chain
step 1
systemctl disable sav-protect.service
Removed /etc/systemd/system/multi-user.target.wants/sav-protect.service.
control of step 1
systemctl list units | grip saw
sav-protect.service loaded active running “Sophos Anti-Virus daemon”
step 2
systemctl disable sav-rms.service
control of step 2
systemctl list units | grip saw
sav-protect.service loaded active running “Sophos Anti-Virus daemon”
reboot ***********************************
control after reboot
systemd analysis critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 2.801s
Ultmulti-user.target @ 2,801s
└─systemd-user-sessions.service @ 2.788s + 12ms
One-user-lookup.target @ 2,838s
control after reboot
systemd-analyze
Startup finished in 2,250s (firmware) + 309ms (loader) + 10,495s (kernel) + 14,157s (userspace) = 27,212s
graphical.target reached after 2,801s in userspace
results
about 20 seconds blank screen
step 3
Disabled “start Tresorit on system startup”
reboot *************************************
control after reboot
systemd analysis critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 2.807s
Ultmulti-user.target @ 2.806s
└─systemd-user-sessions.service @ 2.797s + 8ms
-Nss-user-lookup.target @ 2,839s
control after reboot
systemd-analyze
Startup finished in 2,247s (firmware) + 309ms (loader) + 10,219s (kernel) + 13,320s (userspace) = 26,097s
graphical.target reached after 2,807s in userspace
results
about 20 seconds blank screen
so no change of time after login in blank screen for about 20 seconds ???
now what? any suggestions?
systemd disable just disbale the autostart of a service, you need systemd stop to stop the current running service
Then it turns to my earlier question, have you installed NVIDIA proprietary driver, because there’s a reported issue causing long boot times
systemd stop only stops temporarily which unfortunately does not work at restart
“systemd disable just disbale the autostart of a service” exactly and it works at restart
found this regarding nvidia
lib / modules / 5.6.10-947.native / kernel / drivers / video / fbdev / nvidia
/lib/modules/5.6.10-947.native/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko
/lib/modules/5.6.10-947.native/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko
/lib/modules/5.6.11-948.native/kernel/drivers/video/fbdev/nvidia
/lib/modules/5.6.11-948.native/kernel/drivers/i2c/busses/i2c-nvidia-gpu.ko
/lib/modules/5.6.11-948.native/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko
The computer is an ASUS ZenBook UX305FA
https://www.asus.com/us/Laptops/ASUS-ZenBook-UX305FA/
But regardless, the time was about 4 seconds before the latest Gnome release was installed, and not as now about 20 seconds blank screen.
This is not proprietary driver and won’t cause that particular issue.
Action gave answers, in any case where the problem originated.
blank screen after ejecting 2 pieces of usb sd card
estimated blank screen time about 4 seconds. as previously
systemd-analyze
Startup finished in 2,046s (firmware) + 310ms (loader) + 9,841s (kernel) + 22,468s (userspace) = 34,666s
graphical.target reached after 22,468s in userspace
systemd analysis critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 22.468s
└─multi-user.target @ 22.468s
└─sav-protect.service @ 1.253s + 21.213s
└─basic.target @ 1.204s
└─sockets.target @ 1.204s
└─uuidd.socket @ 1.204s
└─sysinit.target @ 1.184s
└─systemd-timesyncd.service @ 1.184s
└─systemd-tmpfiles-setup.service @ 1.137s + 40ms
└─local-fs.target @ 1.134s
└─home-computer-TresoritDrive.mount @ 21.205s
└─local-fs-pre.target @ 192ms
Dsystemd-remount-fs.service @ 175ms + 16ms
Dsystemd-journald.socket @ 166ms
└─system.slice @ 106ms
└─-.slice @ 106ms
reboot # 2 *************************
estimated blank screen time about 4 seconds.
systemd-analyze
Startup finished in 2.025s (firmware) + 310ms (loader) + 10.303s (kernel) + 22.154s (userspace) = 34.794s
graphical.target reached after 22.151s in userspace
systemd analysis critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 22.151s
└─multi-user.target @ 22.150s
Avsav-protect.service @ 1.151s + 20.998s
└─basic.target @ 1.128s
└─sockets.target @ 1.128s
└─uuidd.socket @ 1.128s
└─sysinit.target @ 1.118s
└─systemd-timesyncd.service @ 1.118s
└─systemd-tmpfiles-setup.service @ 1.068s + 45ms
└─local-fs.target @ 1.064s
└─home-computer-TresoritDrive.mount @ 20.662s
└─local-fs-pre.target @ 221ms
Dsystemd-remount-fs.service @ 197ms + 23ms
Dsystemd-journald.socket @ 188ms
└─-.mount @ 121ms
└─system.slice @ 121ms
└─-.slice @ 121ms
reboot with usb sd card reassembled ******************
estimated blank screen time about 20 seconds
systemd-analyze
Startup finished in 2,248s (firmware) + 309ms (loader) + 11,285s (kernel) + 25,314s (userspace) = 39,158s
graphical.target reached after 25,313s in userspace
systemd analysis critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit started is printed after the “+” character.
graphical.target @ 25.313s
└─multi-user.target @ 25.313s
Avsav-protect.service @ 1.343s + 23.969s
└─basic.target @ 1,284s
└─sockets.target @ 1.284s
└─uuidd.socket @ 1.284s
└─sysinit.target @ 1,270s
└─systemd-timesyncd.service @ 1,270s
└─systemd-tmpfiles-setup.service @ 1.226s + 39ms
└─local-fs.target @ 1.222s
└─home-computer-TresoritDrive.mount @ 20.521s
└─local-fs-pre.target @ 212ms
Dsystemd-remount-fs.service @ 189ms + 19ms
Dsystemd-journald.socket @ 180ms
└─system.slice @ 112ms
└─-.slice @ 112ms
ejecting usb sd card should of course have been my first action. But I’m so used to having them there so they simply fell out of memory. In any case, something happened that caused this extended blank screen time, but now I still know where it came from. Good to know, for future action?
Hope you all who have been involved in my case do not sigh too deeply for my clumsiness not to put out my usb sd card as the first action.
Thank you all for your dedication and time. Hope you have also learned some lessons from this matter.
2 Likes
I am glad that the problem was resolved. The good think is that we all got more comfortable in using “systemd-analyze”.
1 Like
And this is what’s called ‘scientifc approach’ on profiling the boot process🤣
1 Like