[SOLVED] Systemd graphical.target takes a long time to reach

branthebuilder · 2020-05-09 16:37:51

My system seems to boot to a usable state, including GUI, fairly quickly. At least I don't notice any delay. However when I run `systemd-analyze` after boot I get

Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

With output from `systemctl list-jobs` as:

JOB UNIT             TYPE  STATE
1   graphical.target start waiting
99  urserver.service start running

Eventually graphical.target is running:

systemd-analyze
Startup finished in 14.380s (firmware) + 115ms (loader) + 4.397s (kernel) + 1min 33.093s (userspace) = 1min 51.986s
graphical.target reached after 1min 33.089s in userspace

As the system is usable I'm not too worried about this beyond just not understanding what is going on. Suggestions for how to troubleshoot this?

Last edited by branthebuilder (2020-05-16 23:31:19)

zenbum · 2020-05-09 19:00:20

Is graphical.target waiting for urserver.service to finish starting?

I would start with these:

$ systemctl list-dependencies graphical.target
$ systemctl list-dependencies graphical.target | fgrep urserver.service
$ systemctl status urserver.service
$ journalctl -b0 -u urserver.service

Trilby · 2020-05-09 20:06:35

branthebuilder wrote:

Suggestions for how to troubleshoot this?

It doesn't sound like there's any trouble to shoot. Everything seems as expected if 'urserver' may take some time to start. What is 'urserver'? I don't see a service file for this in the main repos, nor does it as a keyword result in any AUR results.

seth · 2020-05-09 20:48:26

The oracle of Mountainview knows it
https://aur.archlinux.org/cgit/aur.git/ … ote-server

Trilby · 2020-05-09 21:17:30

A system service that requires a DISPLAY variable in the environment? That smells fishy. And just hardcoding the assumption that the proper DISPLAY is :0??! That's smells like fish that's been decomposing for a year or so in a well-used but never cleaned port-a-botty trough.

loqs · 2020-05-09 21:41:51

As a system service file it would run /bin/bash /opt/urserver/urserver-start --no-manager --no-copy as root. So would $HOME be set to root when that shell script does:

EXEC_PATH="/opt/urserver/urserver"
PID_PATH="$HOME/.urserver/urserver.pid"
ICON_PATH="/usr/share/icons/hicolor/96x96/apps/urserver.png"
REMOTES_PATH="$HOME/.urserver/remotes"
BACKUP_PATH="$HOME/.urserver/backup"

....

   mkdir -p "$HOME/.urserver"
   $EXEC_PATH --remotes=$REMOTES_PATH --daemon --pidfile=$PID_PATH

Last edited by loqs (2020-05-09 21:45:31)

Trilby · 2020-05-09 23:09:46

Yup.

But I just checked out the package. The path to that service file in the package is /usr/lib/systemd/user/urserver.service. So it should be run a user service.

Branthebuilder, this is your problem, you are running what is meant to be a user service as a system service.

That still doesn't really excuse the assumption of explicitly setting DISPLAY to :0 - in fact it's almost worse, as a properly configured user service would inherit the proper environment. So exporting DISPLAY=:0 in the service file either does nothing useful, or breaks the service completely.

EDIT: ah, it's not an upstream service, that's the AUR packager's work. I'll comment there momentarily.

Last edited by Trilby (2020-05-10 00:13:49)

loqs · 2020-05-09 23:53:28

Possibly urserver-start could be skipped instead using something such as:

[Service]
Type=forking
ExecStart=/opt/urserver/urserver --remotes=%h/.urserver/remotes --daemon --pidfile=%t.urserver.pid
Pidfile=%t.urserver.pid
RuntimeDirectory=urserver

branthebuilder · 2020-05-12 00:46:53

Trilby wrote:

Yup.
But I just checked out the package. The path to that service file in the package is /usr/lib/systemd/user/urserver.service. So it should be run a user service.
Branthebuilder, this is your problem, you are running what is meant to be a user service as a system service.
That still doesn't really excuse the assumption of explicitly setting DISPLAY to :0 - in fact it's almost worse, as a properly configured user service would inherit the proper environment. So exporting DISPLAY=:0 in the service file either does nothing useful, or breaks the service completely.
EDIT: ah, it's not an upstream service, that's the AUR packager's work. I'll comment there momentarily.

Thanks! I have that service on other machines without this problem. Not sure what I did differently to set it up as a system service rather than a user one. That 1 min 33 sec to reach graphical.target is now back to the 2-3 seconds I expected.

Arch Linux

#1 2020-05-09 16:37:51

[SOLVED] Systemd graphical.target takes a long time to reach

#2 2020-05-09 19:00:20

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#3 2020-05-09 20:06:35

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#4 2020-05-09 20:48:26

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#5 2020-05-09 21:17:30

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#6 2020-05-09 21:41:51

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#7 2020-05-09 23:09:46

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#8 2020-05-09 23:53:28

Re: [SOLVED] Systemd graphical.target takes a long time to reach

#9 2020-05-12 00:46:53

Re: [SOLVED] Systemd graphical.target takes a long time to reach

Board footer