[olivercalder]

Summary

The snap currently enables the gateway user service globally, while the .deb and .rpm require manually enabling it for a single target user. This means that snap users can have issues if there are multiple users logged in or the greeter session takes several seconds to stop services after a user logs in. So make the snap match the other packaging formats.

Related Issue

Closes #4614

Changes

• Stop globally enabling the gateway user service by default
• Adjust snap hooks to reflect this, leaving user enablement to manual systemctl --user control
• Have install.sh manually enable the gateway user service for the target user, like it does for other packaging formats
• Update the snapcraft.yaml description (snap info) to explain this

Testing

• Checks appropriate to the affected code and behavior pass
• Unit tests added/updated (if applicable)
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[TaylorMutch]

/ok to test a6782b0

[TaylorMutch]

The fresh-install path looks consistent with the native packages, but the upgrade path needs a migration before merging.

Existing user-mode installations already have the gateway globally enabled. Removing snapctl start --enable from snap/hooks/configure prevents future enablement, but does not clear that existing state. Meanwhile, snap/hooks/post-refresh immediately exits for gateway-mode=user. Users upgrading from an affected revision can therefore retain the same competing gateway startups reported in #4614.

Please add an explicit migration to the selected-user model and an upgrade test starting from a globally enabled revision. The new second-user canary covers fresh installation only.

The focused installer, packaging, wrapper, and snap-hook tests pass. I have not verified a live Ubuntu snap installation or upgrade.

[TaylorMutch]

Alternatively @olivercalder we can acknowledge this is for new installs if we aren't concerned about upgrades, but I just want to understand the impact before we declare that.

[github-actions]

Compatibility review (advisory)

New or updated breaking changes; see the full report for all findings.

1. configuration — No explicit risk acceptance found

sudo snap install openshell and sudo snap set openshell gateway-mode=user formerly enabled and started openshell.user-gateway; they now require systemctl --user enable --now snap.openshell.user-gateway.service.

• Impact: Direct-install and mode-switch automation reaches registration or status checks with no gateway listening at 127.0.0.1:17670.
• Action: Restore automatic user-gateway activation for v0.1.5, or defer opt-in activation to a permitted train with notice and the documented systemctl --user migration.
• PR: fix(snap): only enable gateway user service for one user #4615

Review details

• Execution: complete
• Candidate: PR #4615 (c4f25d9980e3a710f7c4f53cd854753ade52e064)
• Baseline: c3ca45f1dd2848a01309569944e06977e73ff47b (c3ca45f1dd2848a01309569944e06977e73ff47b)
• Reviewed: rust-sdk, python-sdk, go-sdk, typescript-sdk, api-behavior, cli, configuration, policy, helm, state

Advisory review; publication gates are unchanged.

Branch check run

[olivercalder]

@TaylorMutch

Please add an explicit migration to the selected-user model and an upgrade test starting from a globally enabled revision. The new second-user canary covers fresh installation only.

Alternatively @olivercalder we can acknowledge this is for new installs if we aren't concerned about upgrades, but I just want to understand the impact before we declare that.

Ideally, the post-refresh hook could globally disable the user service, but there's not actually a way to do that from within a snap hook without also disabling the services on a per-user basis for all users which happen to be logged in at the time of the refresh, which would likely include the target user in question. And if this is put in the post-refresh hook, then it would run after ever subsequent refresh, so it would keep disabling the user's gateway service, which would be very annoying. I'm working on a rework of the snap/snapctl service commands for snapd which should rectify this in the medium term (probably in the next 6-12 months depending on priorities), but that's not something that can help us at the moment.

So I'm inclined to put this in the documentation rather than try to add some complicated migration workaround that we then have to live with. Doing something in install.sh isn't worth it either IMO, as snap users have basically no reason to ever run install.sh again after they've already installed the openshell snap, since they get automatic updates. Due to the automatic updates, I think the need for migrations from old versions of the snap is lessened compared to other packaging formats, as we can expect users to basically always be running latest/stable or latest/edge unless they explicitly hold back refreshes for some reason, which is rare. There is already rather a lot of complexity in the snap packaging as a result of trying to migrate old setups, which I'd like to reduce or at least avoid expanding in the future.

[TaylorMutch]

Okay sounds ok to me then @olivercalder !

[olivercalder]

Let me push a small comment about this...

[TaylorMutch]

/ok to test 32da1c6