Today's article is about finding the processes that slow down your boot time...

[KGIII]

This is only valid for those of you who are using systemd. If you're not using systemd, this article will not help you.

What it will do is show you how to examine your boot processes, looking for things that slow you down or that are causing problems. It's not really written with the idea of people speeding up their boot process, though it can certainly be used that way, it's for those who are having legitimate boot problems.

As I said in the article, at least with modern computers, I don't really understand spending three hours to shave three seconds off your boot time. You'd actually save more time by not doing that, unless you're rebooting dozens of times every day. Ah well... Tweakers gonna tweak! (And not in the meth way.) Or, as they say, "If it ain't broke, tweak it!" Or not... There's all sorts of things worth tweaking, but shaving a few seconds off your boot time probably isn't gonna help you save all that much time in the long run.

Find The Boot Processes That Slow You Down • Linux Tips

In today's article, we're going to show you how to find the boot processes that slow you down. What you do with this info is up to you.

linux-tips.us

Enjoy and don't forget feedback!

 

[BigBadBeef]

I'm in the login screen usually by the time my monitor powers on, and this is on a 7 year old pci-e 3.0 prototype rev3 m.2 storage system.

Unless I go poking around in the kernel, whatever I add to boot seems to activate after I'm already in my desktop environment.

What could possible slow down systemd from booting?

 

[KGIII]

What could possible slow down systemd from booting?

It's often dependency issues or some program that has added a service that starts at boot that takes quite a while. If you meander around the forum, you'll find the occasional question where people have boot times (on modern devices) that are a couple of minutes long. The solution is often different for each person, but the first step is checking to see what's loading, how long it takes to load, and when it is loading.

 

[BigBadBeef]

It's often dependency issues or some program that has added a service that starts at boot that takes quite a while. If you meander around the forum, you'll find the occasional question where people have boot times (on modern devices) that are a couple of minutes long. The solution is often different for each person, but the first step is checking to see what's loading, how long it takes to load, and when it is loading.

I see. I would think the kernel could identify that there is an issue with said service and at the very least assert that it isn't loading as it should.

After all, debian is prized for its stability...

 

[KGIII]

I would think the kernel could identify that there is an issue with said service and at the very least assert that it isn't loading as it should.

One might think so, but search for 'slow boot time +Linux' at your favorite search engine. You'll find people complaining about it taking two or four minutes to boot. The first step is to then examine the boot process - unless there are other clues, like they recently cloned the drive to a new drive - where fstab may then have the wrong information. But, generally speaking, you first want to examine the boot process for clues.

 

[bob466]

When I had Mint Cinnamon 19.1 on a HDD...my boot times were 38 seconds to the Login Screen and 16 seconds to the Desktop but now it's on an SSD and now 16 seconds and 5 seconds and that was 3 years ago and is still the same...an SSD makes all the difference.

 

[Condobloke]

The:: systemd-analyze plot > boot.svg ......command produces no output

 

[osprey]

The:: systemd-analyze plot > boot.svg ......command produces no output

I can't say why that command failed for you. That's a drag and it shouldn't fail. In my case there was an output, but imagemagick didn't appear to read the bootup.svg file. It output a dark grey screen which was static and didn't respond to any mouse move. I was able to close imagemagick with the q command.

[[email protected] ~]$ systemd-analyze plot >bootup.svg
[[email protected] ~]$ display bootup.svg
[[email protected] ~]$ ll bootup.svg
-rw-r--r-- 1 flop flop 99K Nov 25 13:18 bootup.svg
[[email protected] ~]$ file bootup.svg
bootup.svg: SVG Scalable Vector Graphics image

On checking about online, apparently it takes some time for imagemagick and other viewing programs to display large .svg files, sometimes many minutes, so perhaps I didn't wait long enough for imagemagick to do it's work. Normally I sort of expect it to display almost immediately. Notwithstanding that, the .svg file was entirely visible when I pointed my browser, firefox, at the file. There was no time delay with the browser and I was able to move about the image of the graph which was actually larger than my monitor screen. It's basically a graph representing the output from the the command: systemd-analyze blame, as far as I could see so if one is satisfied with the terminal output from that command, that's just as informative.

 

[Condobloke]

It has me stumped. I obliterated Gnome Terminal... sudo apt purge gnome-terminal.... and started using Tilix in that process.


Still no result.

 

[BigBadBeef]

One might think so, but search for 'slow boot time +Linux' at your favorite search engine. You'll find people complaining about it taking two or four minutes to boot. The first step is to then examine the boot process - unless there are other clues, like they recently cloned the drive to a new drive - where fstab may then have the wrong information. But, generally speaking, you first want to examine the boot process for clues.

Never mind, I was just back from "happy hours" when I wrote that so just ignore it...

 

[osprey]

It has me stumped. I obliterated Gnome Terminal... sudo apt purge gnome-terminal.... and started using Tilix in that process.


Still no result.

This is curious. I expect your system will certainly have the binary executable: systemd-analyze, since it's part of the systemd package. It shouldn't be the terminal emulator that gets in the way. In my own case I use xterm for most operations, sometimes termit, lxterminal or st, which all work with systemd-analyze. They are all light weight compared to gnome-terminal in terms of install size plus dependencies.

 

[Condobloke]

 

[Condobloke]

each time i open a terminal (regardless of which one) i get...

No idea if it interferes in any way...??

That 'blurb' transfers from one terminal 'brand' to the next...

 

[f33dm3bits]

each time i open a terminal (regardless of which one) i get...

View attachment 14053
No idea if it interferes in any way...??

That 'blurb' transfers from one terminal 'brand' to the next...

The errors you are getting there are most likely referring to the lines in one of these files:
~/.bashrc
~/.bash_profile
I would check them first.

 

[f33dm3bits]

The:: systemd-analyze plot > boot.svg ......command produces no output

It's correct that it produces no output because the output is redirected to a file or does the file boot.svg also not get created or it does but you see nothing when you open it?

 

[Condobloke]

Maarten....you have hit the nail on the head !

The output has been redirected to a file....boot.svg....in /home/brian

 

[Condobloke]

That will give @KGIII something to edit into his blurb up above.......

 

[Condobloke]

and in your post @f33dm3bits #14....I found the culprit...error messages gone!....Thank you.!

 

[osprey]

Condobloke wrote:

The output has been redirected to a file....boot.svg....in /home/brian

I'm sorry if the code and explanation in post #8 was confusing.

 

[Condobloke]

I can easily admit that my own haste is to blame there......that and the fact that I assumed that the result would show itself in the terminal.
There are times that a person's inexperience (mine) shows.....and this is one of them

Thanks for your help, @osprey, and you too @f33dm3bits