fix(linux): fix systemd service file

[gdesmott]

Description

A couple of changes ensuring the service is properly started after graphical-session.target.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ReenigneArcher]

I think we actually need a way to handle different environments... because this file just keeps getting changed back and forth.

https://github.com/LizardByte/Sunshine/commits/92b4eeee55002395ef4d6adc244e357c1eb7bc9f/sunshine.service.in?browsing_rename_history=true&new_path=packaging/linux/sunshine.service.in&original_branch=master

[gdesmott]

I'm not an expert but as I understand it graphical-session.target is a better fit as not all desktop environment will enable xdg-desktop-autostart while graphical-session.target is just Wayland itself.

Is there any setup where xdg-desktop-autostart is enabled but graphical-session.target is not?

[ReenigneArcher]

I am not an expert either, but we do need to handle non wayland environments.

I found this (https://systemd.io/DESKTOP_ENVIRONMENTS/), maybe it has some answers.

[psyke83]

I think xdg-desktop-autostart fits better because it is started by (and thus after) graphical-session. My understanding of the distinction is that graphical-session will cover initialization of low-level services needed to start a graphical session such as Xorg and wayland compositors, whereas xdg-desktop-autostart is focused on apps to be started within the actual graphical session. Sunshine should be treated more like the latter than former because we depend on the graphical session first being initialized in order for capture initialization to work.

What distro(s) are not shipping xdg-desktop-autostart? Perhaps the addition of "After=graphical-session.target" might be an acceptable middle-ground if this really is an issue with some distributions (and thus you will have to depend on the 5 second delay in the service file to hope that your graphical session actually finishes loading before sunshine initialization starts), but I agree with @ReenigneArcher that changing the base xdg-desktop-autostart dependency is wrong.

[xiaozhangup]

However, on Fedora 43 with GNOME, xdg-desktop-autostart is not started, while on KDE it is. As a result, xdg-desktop-autostart may not be a stable point of reference.

[gdesmott]

on Fedora 43 with GNOME, xdg-desktop-autostart is not started

Yes, I'm using that as well, that's why I changed it to graphical-session.target.

[psyke83]

I think we don't need to map out distros in such detail. The basic issue is that the standard GNOME desktop doesn't use xdg-desktop-autostart.target.

Fedora 43 GNOME:

$ systemctl --user | grep xdg
  xdg-desktop-portal-gnome.service                                                                                        loaded active running   Portal service (GNOME implementation)
  xdg-desktop-portal-gtk.service                                                                                          loaded active running   Portal service (GTK/GNOME implementation)
  xdg-desktop-portal.service                                                                                              loaded active running   Portal service
  xdg-document-portal.service                                                                                             loaded active running   flatpak document portal service
  xdg-permission-store.service                                                                                            loaded active running   sandboxed app permission store
  
$ systemctl --user status xdg-desktop-autostart.target
○ xdg-desktop-autostart.target - Startup of XDG autostart applications
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-autostart.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

I don't have the log handy, but Fedora 43 KDE does start the xdg-desktop-autostart.target by default.

Given that 1/2 major DEs don't use this unit file, we shouldn't rely on it - but we can still use it for startup service ordering.

My recommendation:

• Important: make sure to update both unit files.
• For both files, set WantedBy=graphical-session.target in [Install].
• In both files, set After=graphical-session.target xdg-desktop-autostart.target in [Unit] section.
• In sunshine.service.in, append xdg-desktop-portal.service to After list in the [Unit] section (but there's probably no harm in putting it in the kms service as well).

In summary:

• WantedBy=graphical-session.target will correctly set the service enable/disable dependency chain that should work on all major distros.
• The After= entries will be treated as weak ordering dependencies, meaning that if the units exist, they will be started before Sunshine, but if they don't exist on any given system, Sunshine will not be preventing from starting.

[ReenigneArcher]

@gdesmott could you rebase this PR and update it with @psyke83's findings?

To add clarification, there is a new service file sunshine-kms since you opened this PR initially.

[gdesmott]

I won't be able to test it for now so @psyke83 feel free take the relevant bits from my PR and open a new one.