last day (15 days later) » 

20:23
1
Q: Boot lagging caused by text output

GrimI installed Ubuntu 22.10 Desktop and the boot process is very fast (< 3 seconds). On a installed Ubuntu 22.10 Server the boot sequence is pretty slow (> 60 seconds). I try to do a graphical boot but I failed. In order to enable the graphical boot I did : grim@main:~$ sudo systemctl set-default gr...

aside from the title ;) But yeah, I retract my close vote and will clean up that comment. Do, still, run system-analyze blame to figure out what takes the most time :)
@MarcusMüller Most time took postgresql.
that is kind of a good thing – that's probably due to this being a database server with a lot of data to be loaded from disk for its purpose, no?
Its a 1 megabyte database, I dont think that the first step in boot is to make sure postgres is working.
oha! that's not good. It should take fractions of a second to start postgresql. Is the storage device on which that postgres database is in good shape?
It's not "the first step". It's one of the step necessary to complete system boot, and your systemd-analyze blame says it's the one that takes the longest. That indicates a problem with loading that database.
20:23
The boot lags from beginning. And it does not lag in ubuntu-desktop 22.10. And it is only a 1 Megabyte database. I think this is going into the wrong direction.
I added the storage device benchmark to the question.
yeah, you can assume that, but you also said that sudo systemd-analyze blame says that it's the unit that takes the longest, so, there's a conflict between the assumption this isn't related to the problem and that fact :) Anyways, would you care to add the output of sudo systemd-analyze critical-chain multi-user.target to your question? That might be very helpful :)
(you can also replace multi-user.target with the service that needs to run for you to consider the server to be "up", for example, if that was the SSH service, sudo systemd-analyze critical-chain sshd.service)
I added the output of sudo systemd-analyze critical-chain multi-user.target.
You said: "oha! that's not good. It should take fractions of a second to start postgresql", yes, it took under one second. And that was the slowest candidate. You asked for the slowest. I answered correctly: postgres was the slowest.
Well, then that's still surprising, but not as bad. So, critical boot chain would be even more relevant. You say everything is slow – I fully believe that – but we'll need to figure out what it is that makes everything slow. As said, the speed at which boot messages scroll by isn't the limiting factor. Nothing (aside from systemd as it prints these messages) cares about your display's text speed. Modern boot systems including yours start services, massively parallel, in the background; that's why I dig so persistently. And what we see is the following surprising result:
multi-user.target is ready after 12s, which I think we both would consider reasonably fast, until your server machine is ready to do server things. So, that means the question shifts a bit: What thing is it that you need to have happened / be ready for you to consider your server to be "booted"?
@MarcusMüller Wait, only the boot-sequence is slow. After booting everything else is fast as hell!
For me a system is considered to be finished booting when the system has successfully finished compleatly runlevel 2 but not even a bit touched runlevel 3.
there's not been runlevels in Ubuntu since 15.04, only targets ;) So, but yeah, if I remember correctly, though, a Ubuntu runlevel of 2 was "all network-facing services are started", right? In that case, what your critical-chain tells us that's the case after 12.567 seconds!

last day (15 days later) »