Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-5092GitHub issuePublicReceived

sunshine install fails to enable service: unit name mismatch

Reported by higorhgon · filed Sep 15, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #7050 (R-1810). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

sunshine install fails to enable service: unit name mismatchrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

Running omarchy install service sunshine installs the package successfully but then fails with:

Failed to enable unit: Unit sunshine.service does not exist

Root cause

omarchy-install-service-sunshine (in omarchy/bin) runs:

systemctl --user enable --now sunshine

but the sunshine package actually ships its systemd user unit as app-dev.lizardbyte.app.Sunshine.service:

$ pacman -Ql sunshine | grep -i service
sunshine /usr/lib/systemd/user/app-dev.lizardbyte.app.Sunshine.service

There is no unit literally named sunshine.service, so the enable/start step fails while everything else in the script (firewall rules, admin web app install, Hyprland autostart entry) still runs and reports success. The result is a Sunshine install that looks complete but isn't actually running/enabled until the user manually enables the correctly-named unit.

Steps to reproduce

  1. omarchy install service sunshine
  2. Observe the package installs fine, but the script errors with Failed to enable unit: Unit sunshine.service does not exist
  3. systemctl --user status sunshine → unit not found
  4. systemctl --user status app-dev.lizardbyte.app.Sunshine.service → exists but is not enabled/running

Expected behavior

The install script should enable/start the unit under its real name, e.g.:

systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service

(optionally via a variable at the top of the script, in case the upstream unit name changes again), so the service actually starts and the install completes cleanly.

Workaround

systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service

System info

  • Omarchy: 4.0.0.r2138.gf2b419d-1 (omarchy-dev)
  • sunshine package: 2026.906.222525-1.2 (omarchy repo)
  • Kernel: 7.2.4-arch1-2
  • Desktop: Hyprland 0.56.2, SDDM
  • CPU: Intel Core i5-7200U (Kaby Lake)
  • Machine: Acer Aspire A515-51 (laptop)
View raw text
## What happened

Running `omarchy install service sunshine` installs the package successfully but then fails with:

```
Failed to enable unit: Unit sunshine.service does not exist
```

## Root cause

`omarchy-install-service-sunshine` (in `omarchy/bin`) runs:

```bash
systemctl --user enable --now sunshine
```

but the `sunshine` package actually ships its systemd user unit as `app-dev.lizardbyte.app.Sunshine.service`:

```
$ pacman -Ql sunshine | grep -i service
sunshine /usr/lib/systemd/user/app-dev.lizardbyte.app.Sunshine.service
```

There is no unit literally named `sunshine.service`, so the enable/start step fails while everything else in the script (firewall rules, admin web app install, Hyprland autostart entry) still runs and reports success. The result is a Sunshine install that looks complete but isn't actually running/enabled until the user manually enables the correctly-named unit.

## Steps to reproduce

1. `omarchy install service sunshine`
2. Observe the package installs fine, but the script errors with `Failed to enable unit: Unit sunshine.service does not exist`
3. `systemctl --user status sunshine` → unit not found
4. `systemctl --user status app-dev.lizardbyte.app.Sunshine.service` → exists but is not enabled/running

## Expected behavior

The install script should enable/start the unit under its real name, e.g.:

```bash
systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service
```

(optionally via a variable at the top of the script, in case the upstream unit name changes again), so the service actually starts and the install completes cleanly.

## Workaround

```bash
systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service
```

## System info

- Omarchy: `4.0.0.r2138.gf2b419d-1` (omarchy-dev)
- sunshine package: `2026.906.222525-1.2` (omarchy repo)
- Kernel: `7.2.4-arch1-2`
- Desktop: Hyprland 0.56.2, SDDM
- CPU: Intel Core i5-7200U (Kaby Lake)
- Machine: Acer Aspire A515-51 (laptop)

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.