Skip to content

Support configuring restart policy of services in the Package Compose project #1747

@junhaoliao

Description

@junhaoliao

Request

We should improve how CLP behaves when run as a long-running service.

Right now, the Compose project does not specify any restart policy, so services neither restart on failure nor persist across system reboots. This has led to two distinct user needs:

  1. One-off launches (default)
    • Users want to run CLP temporarily (for development, testing, or production) without leaving persistent services running after a reboot.
    • This is our current behavior and should remain the default, since enabling persistence (e.g., unless-stopped) would be an intrusive change and a departure from past expectations.
  2. Persistent service installs
    • Other users have asked for CLP to behave like a service that survives reboots.
    • This requires a different restart policy: restart: unless-stopped.

Possible implementation

Option 1: Add an argument to start-clp.sh

To support both use cases in a controlled and explicit way, we should expose restart behavior as a deliberate choice.

Introduce a clear argument to start-clp.sh such as:

--restart-policy=<policy>

Where directly maps to Docker Compose values:

  • restart: "no"
  • restart: on-failure
  • restart: on-failure:3 (default)
  • restart: unless-stopped

This makes service intent explicit and avoids surprising users with persistent containers after a reboot.

Option 2: (on top on Option 1) Add an Installation Wrapper (install-clp.sh)

Provide a script that runs start-clp.sh --restart-policy=unless-stopped and runs CLP in service mode.

Pros: Clean separation between “run once” and “install as a service”.
Cons: Additional script to maintain.

Option 3: Systemd Integration

Generate a systemd service via a helper script (e.g., tools/install-systemd-service.sh).

Pros: Proper OS-level service management; survives reboots cleanly.

Cons: Platform-specific.

Option 4: Documentation-Only

Document how to specify --restart-policy manually in Docker Compose for persistent mode.

Pros: Minimal development cost.

Cons: Less discoverable; intent is not as clear; users have to modify the docker-compose.yaml on every new release

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions