You are not logged in.
hey guys,
I've been thinking about writing a shell script to optimize the boot-time (or time for kernel space + user space + graphical target). I've figured out that the display managers (Graphical ones) usually take some time to load the desktop environment. This time can be utilized to load some services (which are not base services) like bluetooth, thermald, docker etc on login.
I can sift through the `systemd` services to find out which ones are not `RequiredBy` any other service, and takes a long time to load (a threshold would have to be specified). Then i can disable these services and create a shell script to be executed on login, which would start these services.
I'm looking for comments on this idea. are there any security implications? etc.
Thanks.
Offline
One of the major benefits of systemd is that it does all of that, correctly and quickly already, what do you expect to gain?
When you reach the "slow" display manager service, all the other ones you mention will have already started.
I suspect an XY problem, what actual issue do you see and what do you think could be optimized? Have you already checked the output of
systemd-analyze blame
systemd-analyze critical-chain
Last edited by V1del (2018-09-13 16:23:28)
Offline
One of the major benefits of systemd is that it does all of that, correctly and quickly already, what do you expect to gain?
When you reach the "slow" display manager service, all the other ones you mention will have already started.
I suspect an XY problem, what actual issue do you see and what do you think could be optimized? Have you already checked the output of
systemd-analyze blame systemd-analyze critical-chain
My goal is to have a system that gives me a desktop environment in as little time as possible. I stumbled upon this idea - taking care of on-boot services - to achieve that goal.
i have read that systemd parallelizes resource initialization by creating auxiliary units. But, despite that the boot-time in my case was usually over 32 seconds (i have a spinning hdd). I did a `systemd-analyze blame` and `systemd-analyze critical-chain` to find out that somehow `ModemManager.service` was taking 12-15 seconds to load. I disabled it, and wrote a login script to start that service on login. And my boot time actually went down to 23 seconds something. A gain of 9 seconds!
And thank you for that link, i'd be careful of avoiding the XYProblem in future. Thanks again.
Last edited by mapcode.mind (2018-09-13 17:15:26)
Offline
"Message" is a required field in this form.
Last edited by linux-mate (2020-01-05 21:58:33)
Offline
I just disabled services which i do not need. I start some of services after bootup with my custom service. This way my systemd-boot is below 2 seconds. From power button to desktop myu laptop needs 12 seconds.
If i had installed arch in UEFI mode and booted kernel directly without grub i am sure it would tun on in less then 9 seconds.
P.S.
You want your startup to be faster disable unnececery services and switch to lighet environment like i3 WM. Use tty login not gui one. This way i am sure your boot time will be less then 16 seconds.
can you suggest some good console-based login managers? or how can i start my windows manager from a tty-based login?
Offline
agetty(8) is launched by default, I believe.
I generally log in there and start my window manager with `exec startx`. Works fine for me.
EDIT I just realised that agetty might not really be a "login manager" in the same way as display managers. But it's text based, and simple, at least
Last edited by ayekat (2018-09-26 11:49:44)
Offline
`startx` should work, but i don't know how to start the different dekstop sessions i have installed like plasma, steam, plasma-wayland etc.
Offline
Offline
My xinitrc has something like this:
wm=${wm:-foo} ... $wm
I can then call startx with
wm=foobar startx
and this will start `foobar` instead of the default `foo`.
oh, thanks. Let me try this.
Offline
So this is an X-Y problem stemming from misunderstanding systemd-analyze output. Just because a backgrounded service takes 32 seconds to finish it's startup doesn't mean it is delaying the time until you are in you desktop in any way. Disabling that service and starting it manually later will have no effect on the actual time until you are in your desktop - it will only artificially deflate the numbers in systend-analyze's output while also making that single service take *much* longer to be ready.
(Replacing a DM with an autologin and automatically running startx/xinit will likely give a slight speed boost, but perhaps very slight).
Last edited by Trilby (2018-09-26 13:16:02)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
`startx` should work, but i don't know how to start the different dekstop sessions i have installed like plasma, steam, plasma-wayland etc.
Offline
So this is an X-Y problem stemming from misunderstanding systemd-analyze output. Just because a backgrounded service takes 32 seconds to finish it's startup doesn't mean it is delaying the time until you are in you desktop in any way. Disabling that service and starting it manually later will have no effect on the actual time until you are in your desktop - it will only artificially deflate the numbers in systend-analyze's output while also making that single service take *much* longer to be ready.
(Replacing a DM with an autologin and automatically running startx/xinit will likely give a slight speed boost, but perhaps very slight).
oh, i didn't realize that. i just thought that if `systemd-analyze critical-chain` shows a high enough number after + besides a process, that is the absolute time it takes for that process to start.
@2ManyDogs : thank you for this.
Last edited by mapcode.mind (2018-09-26 21:02:01)
Offline
So far we only have systemd time data, right? But what you're interested in is the time from zero to working desktop. There is only one good method to measure that, and it involves a stopwatch. Is there a measurable difference in real time if you let systemd do the scheduling or activate the service later? Could be that some dependencies aren't set right in some unit files then.
Last edited by Steef435 (2018-09-26 21:18:56)
Offline
that is the absolute time it takes for that process to start.
It is. But if it started in the background (which it is) it can still be "starting" after you are already in your desktop checking your email and looking up pictures of cats. Xorg doesn't wait for all other processes to start - and if your DM does wait, then that is a bug in your DM (and or it's systemd service file) that should be fixed.
Theoretically one could add an artificial service that would have an arbitrarily long start time, or even never finish 'starting' and so systemd-analyze would report it was either not started or took a ridiculously long time to start ... but enabling this artificial service would have no effect on when or whether you you get into your desktop and do whatever it is you do on your system.
Last edited by Trilby (2018-09-26 21:20:53)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline