Default systemd doesn't work after reboot, requires manually launch

[iaomw]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the nightly release?

• This issue is present in the nightly release

Describe the Bug

I am trying then deb package from github release. It works well except the default systemd config.

/usr/lib/systemd/user/sunshine.service;

It never work after reboot. And I noticed the contents is different from your document.
There are many xdg-desktop-autostart.target comparing to your documents.

Expected Behavior

No response

Additional Context

No response

Host Operating System

Linux

Operating System Version

kubuntu 22.04.3 with Kernel 6.2.0

Architecture

64 bit

Sunshine commit or version

0.20.0

Package

Linux - deb

GPU Type

Nvidia

GPU Model

RTX 3070 Ti

GPU Driver/Mesa Version

535.86.05

Capture Method (Linux Only)

No response

Config

I never touch it.

Apps

No response

Relevant log output

not related

[ReenigneArcher]

I noticed the contents is different from your document

Does the service listed in the documents work?

[iaomw]

I noticed the contents is different from your document

Does the service listed in the documents work?

No, it doesn't work after reboot. The same.

[xTeixeira]

Doesn't work for me either on Arch Linux using the AUR package. I'm fairly sure it used to work some time ago. I'm using GNOME on Xorg as my desktop.

Either way, IMO a better solution here would be to provide a .desktop file in the packages and let users configure autostart through their DE (or systemd-xdg-autostart-generator). That is what I did as a workaround and it starts fine this way.

[ReenigneArcher]

.desktop file has already been added to nightly releases.

[xTeixeira]

.desktop file has already been added to nightly releases.

Awesome, thanks. :)

To add more context, I believe this problem started after a192c50 was merged. I don't think xdg-desktop-autostart.target is something that works at all in GNOME. Not sure about other DEs. In fact, in my system, manually starting the sunshine unit makes systemd try to start every dependency of xdg-desktop-autostart.target, which isn't something that normally happens on a gnome-session login.

In short, if we really want a working systemd unit (instead of letting users configure autostart through the .desktop entry), we need a rework on the dependencies of the unit file, removing any usage of xdg-desktop-autostart.target in favor of something that works with any DE or WM. That being said I'm not entirely sure how to achieve that. I might try looking more into that later.

[HomerSp]

.desktop file has already been added to nightly releases.

Awesome, thanks. :)

To add more context, I believe this problem started after a192c50 was merged. I don't think xdg-desktop-autostart.target is something that works at all in GNOME. Not sure about other DEs. In fact, in my system, manually starting the sunshine unit makes systemd try to start every dependency of xdg-desktop-autostart.target, which isn't something that normally happens on a gnome-session login.

In short, if we really want a working systemd unit (instead of letting users configure autostart through the .desktop entry), we need a rework on the dependencies of the unit file, removing any usage of xdg-desktop-autostart.target in favor of something that works with any DE or WM. That being said I'm not entirely sure how to achieve that. I might try looking more into that later.

Indeed, as the original author of that commit I can confirm that relying on xdg-desktop-autostart.target isn't the best option. It seems to work just fine for me on plasma, but I've seen reports that it doesn't reliably work on other DEs. The big issue here is that, unfortunately, there doesn't seem to be any universal target you can use that works across all DEs. Previously, for me, sunshine would sometimes start before the DE (when using wayland), causing a black screen on log in because kwin tried to get exclusive to the framebuffer.
I honestly don't know what the best solution here would be, since there doesn't seem to be any universal way to get the systemd service to start after the DE. Maybe it would be best to just drop the systemd service, and rely solely on the .desktop file?

[rockerbacon]

systemd.special(7) says there are only 3 passive user targets: graphical-session-pre.target, graphical-session.target and xdg-desktop-autostart.target.

xdg-desktop-autostart.target exists to help with XDG autostart, but it's part of a separate systemd functionality that not all systems might use. There also doesn't seem to be anything specifying that this target actually runs after the DE is initialized.

Ultimately, graphical-session.target is the last initialization step in the systemd spec. Anything after that is specific to the individual DEs and distributions.

That said, I've had no issues with this unit:

[Unit]
Description=Sunshine is a self-hosted game stream host for Moonlight.
StartLimitIntervalSec=500
StartLimitBurst=5
# delay initialization to after graphical-session.target has been started
After=graphical-session.target

[Service]
ExecStart=/usr/bin/sunshine
# uncomment the line below if your system is reporting session initialization prematurely
# ExecStartPre=/usr/bin/sleep 30 # wait  30s before starting sunshine
Restart=on-failure
RestartSec=5s

[Install]
# activate this unit alongside graphical-session.target
WantedBy=graphical-session.target

The secret is that it leverages systemd's differentiation between weak (WantedBy, Wants) and strong (RequiredBy, Requires) requirements. If a DE is properly configured, it should have all its core services defined as strong requirements and graphical-session.target should receive "started" status only after all of those have started. Meanwhile, the Sunshine unit is defined as a weak requirement and will not keep graphical-session.target from moving to a "started" state, allowing us to initialize Sunshine's after graphical-session.target has finished starting up, even when both are activated at the same time.

The obvious catch is that this relies on DE unit configurations and programs behaving-well. If units report initialization before the actual programs are ready, or if the units have poorly configured requirements, things won't work well. For such cases, I've included a ExecStartPre startup delay that you can use to give your system some additional time to start things up.

[LizardByte-bot]

It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!

[LizardByte-bot]

This issue was closed because it has been stalled for 10 days with no activity.