36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
# ADR 0015: User Service Installation
|
|
|
|
## Status
|
|
|
|
Accepted.
|
|
|
|
## Decision
|
|
|
|
Geth provides direct `geth daemon install|start|stop|status|uninstall` commands
|
|
for the common lifecycle. `daemon install` initializes the selected geth home,
|
|
installs and enables the user service, and starts it immediately. The existing
|
|
`geth daemon service ...` commands remain available for compatibility, explicit
|
|
manager selection, definition previews, and install-without-start behavior.
|
|
Status probes return a normalized state. An inactive or missing service is a
|
|
successful inspection result, while a service-manager access problem is
|
|
reported as `unknown` with the manager's diagnostic rather than mislabeled as a
|
|
stopped daemon.
|
|
|
|
The service is always installed as a user service:
|
|
|
|
- Linux: systemd user unit, `~/.config/systemd/user/geth.service`
|
|
- macOS: launchd user agent, `~/Library/LaunchAgents/local.geth.daemon.plist`
|
|
- Windows: per-user scheduled task named `geth-daemon`
|
|
|
|
The service runs the same single binary as `geth daemon run` and preserves
|
|
`GETH_HOME` in the service environment.
|
|
|
|
## Consequences
|
|
|
|
There are still no separate `gethd` or `gethctl` binaries. Installation does not
|
|
require privileged system service access. Linux users who need the daemon before
|
|
interactive login may still need platform-specific user-service setup such as
|
|
systemd lingering.
|
|
|
|
Future service managers can be added behind the same service-manager enum and
|
|
CLI shape.
|