Repository navigation
fix(snap): only enable gateway user service for a single user #4614
Description
User Story
As an Ubuntu user, I want to be able to run the OpenShell snap with the gateway service running for my user. Currently, the snap globally enables the gateway user service, so if there are multiple users logged in or the greeter session is slow to end, my user gateway can fail to start. For other packaging formats (the .deb and .rpm), the user service remains globally disabled but install.sh manually enables it for the target user, avoiding this issue.
Problem Statement
The gateway user service is globally enabled by default. This causes issues when the greeter session is slow to close, or if multiple users log in, since all gateway user services try to bind to the same port.
Impact / Why This Matters
The greeter session takes ~10 seconds to close down after a user logs in, so if the gateway user service was running for the greeter, then when the user logs in their own gateway user service will fail to start since it can't bind to that port.
Acceptance Criteria
- The gateway user service is not globally enabled by default
- The gateway user service is enabled for the particular user who is running `install.sh
- The snapcraft.yaml description (which populates
snap info) states that the user should manually runsystemctl --user enable --now snap.openshell.user-gateway.serviceafter manually installing the snap without usinginstall.sh
Reproduction Steps
- Create multiple users, enable linger for them or have active logind sessions
- Install the
openshellsnap viainstall.shor directsnap install openshell - See that only one user's gateway service is running, and others failed to start
Suggested UX (if applicable)
No response
Environment
- OpenShell snap which has the user gateway, so the current
latest/stableorlatest/edgerelease
Activity
TaylorMutch commentedon Oct 19, 2026
Assessment: the report is supported by the current source and is ready for human review. The user story provides first-hand Ubuntu context, reproduction steps, impact, and a concrete proposed interaction. An implementation is already open in #4615; no separate implementation is needed.
Evidence checked against main at
2798108b3f555d25f856920da479455aa03bb393:snap/hooks/configurerunssnapctl start --enable openshell.user-gatewayin user mode. Both gateway apps already declareinstall-mode: disable; the configure hook overrides that for the user gateway.install.shdoes not enable the snap unit specifically for its target user and restarts it as root on refresh. The native-package path explicitly enables its unit as the target user.127.0.0.1:17670, consistent with competing user services failing to bind. The existing configure-hook test passes and explicitly expects the global enable command. This is source-level validation, not a reproduction of the Ubuntu greeter timing or a live multi-user snap installation.#4615 addresses target-user activation, manual-install instructions, and adds a second-user canary check. Human review should verify fresh installation and refresh from an already globally enabled revision, including preservation of the chosen user's service and absence of unintended activation for another active/lingering user. The report does not include an exact snap revision or journal output, so the release-specific failure remains unverified.
This is narrower than #4273: selecting one gateway user avoids accidental startup contention; simultaneous gateways for multiple OS users remain separate work. Next decision: maintainer review of #4615 and its Linux validation. This assessment does not record maintainer acceptance.