Some users run Hermes in systemd-enabled containers (e.g. systemd as PID 1 inside Docker). In these environments, systemd user services work perfectly well — systemctl --user is functional, loginctl enable-linger works, and services persist across restarts. The current behavior forces these users to manually create the systemd unit file, which is error-prone.

TL;DR

The issue can be resolved by modifying the hermes_cli/gateway.py to check for systemctl availability and proceed with systemd_install() when --force is passed in a container environment.

Guidance

• Check if systemctl is available inside the container by verifying the output of which systemctl or command -v systemctl.
• Modify the is_container() check in hermes_cli/gateway.py to also consider the availability of systemctl when --force is passed.
• Proceed with systemd_install() when systemctl is available and --force is passed, instead of exiting.
• Test the modified code to ensure it works as expected in both container and non-container environments.

Example

if is_container() and '--force' in sys.argv:
    if shutil.which('systemctl'):
        systemd_install()
    else:
        print("Service installation is not needed inside a Docker container.")

Notes

The suggested fix assumes that the presence of systemctl inside the container indicates that systemd is available and functional. However, this may not always be the case, and additional checks may be necessary to ensure compatibility.

Recommendation

Apply the suggested workaround by modifying the hermes_cli/gateway.py file to check for systemctl availability and proceed with systemd_install() when --force is passed. This will allow users to override the default behavior and install the systemd service inside a container environment.