CLI and service operations

CLI and service operations is the root operator's practical reference for inspecting SHM, identifying the correct systemd unit, restarting only the affected workload, reading its logs, and using supported maintenance tools without guessing.

Where to find it: Documentation > Hosting Manager > Server administration > CLI and service operations.

Available to: Anyone may read this reference. Every local SHM CLI, systemd lifecycle command, and maintenance script on this page must be run from a root shell on the SHM server.

What this page does

Use this page after the Status, Monitor, or Server Logs page identifies a problem. It maps SHM service keys to real unit names, separates saved configuration from measured runtime state, and gives copyable checks for shared services, companion applications, per-account PHP, Node.js, Podman, JailShell, timers, sockets, and supported repair scripts.

This is an operations reference, not a replacement for the owning SHM page. Use Services to install or change the selected stack, account pages for customer-scoped changes, and the commands below for evidence, a narrow lifecycle action, or a documented repair.

Before you start

• Open a root shell through SSH or the root Terminal. The shm, shmlogin, and shmupdate tools reject non-root callers.
• Replace examples such as exampleuser, example.com, APP_ID, and php83 with values returned by SHM. Do not guess an account unit, application id, or PostgreSQL major version.
• Record the current status and recent logs before changing anything. A restart removes useful transient evidence and can interrupt every account using a shared service.
• Use a maintenance window and a verified backup for shared database, mail, DNS, firewall, web-stack, or update work.
• Do not run a repair script while Services Apply, an SHM update, an account migration, or a backup restore is already changing the same area.

All examples omit sudo because the required context is already root. An absent optional unit normally means that feature is not installed in the current Services plan; it is not a reason to create a unit by hand.

Command safety levels

Standard systemd workflow

Start with one exact unit. This example inspects NGINX but works for any unit listed later on this page:

UNIT=nginx.service
systemctl is-enabled "$UNIT"
systemctl is-active "$UNIT"
systemctl status "$UNIT" --no-pager -l
systemctl show "$UNIT" -p LoadState -p ActiveState -p SubState -p MainPID -p NRestarts -p MemoryCurrent -p TasksCurrent
systemctl cat "$UNIT"
journalctl -u "$UNIT" --since "-15 minutes" --no-pager

systemctl cat shows the installed unit and drop-ins; it does not edit them. ActiveState=active and a healthy application check are stronger evidence than is-enabled, which only describes boot policy.

Before reloading a web service, validate its configuration and confirm that the unit supports reload:

nginx -t
httpd -t
systemctl show nginx.service -p CanReload --value
systemctl reload nginx.service
systemctl is-active nginx.service

Run only the test for the installed web stack. In NGINX plus Apache mode, validate both before reloading either. If CanReload=no, the configuration test fails, or the executable/runtime itself must be replaced, do not force a reload; fix the reported cause or use a planned restart.

UNIT=nginx.service
systemctl restart "$UNIT"
systemctl is-active "$UNIT"
systemctl status "$UNIT" --no-pager -l
journalctl -u "$UNIT" --since "-5 minutes" --no-pager

systemctl reset-failed UNIT only clears the failed marker after the underlying cause is fixed; it does not repair configuration. Avoid broad commands such as restarting every unit at once.

SHM CLI and server information

The root-only shm command calls the same bounded Engine operations used by SHM. Use --pretty for readable JSON and ask the live catalog for help instead of relying on an old command list.

shm --help
shm list
shm list --all
shm help root-services-status
shm health list --pretty
shm root-server-information list --pretty
shm root-services-config list --pretty
shm root-services-status list --pretty
shm root-update-state list --pretty
shm license-status list --pretty
shm accounts list --pretty

For complete endpoint parameters and role boundaries, use shm help CATEGORY and the Root API reference. Do not use a private /v1/internal/... route as a customer integration.

SHM Login and updates

SHM Login. shmlogin generates short-lived root autologin URLs on port 882. The default lifetime is 60 seconds and each link is single-use. Bind it to the administrator's current public IP whenever possible:

shmlogin --help
shmlogin --url https://panel.example.com --ttl 60 --ip 192.0.2.10

The output is a root credential in URL form. Do not paste it into tickets, chat, documentation, screenshots, shell transcripts, or monitoring. --multi permits reuse until expiry and should be reserved for a specific controlled need.

SHM updates. Check first, then apply in a maintenance window:

shmupdate --help
shmupdate --check
shmupdate --check --json
shmupdate

shmupdate --force reapplies the current channel version and is a repair action, not a normal update check. The guard file /opt/shm/.shm/.do.not.update blocks all updates, including forced ones. If the canonical shmupdate command is missing on a supported installation, do not invent a replacement symlink; use the supported repair path. See Version and updates.

Shared service reference

These are the source-defined SHM service keys and their real systemd units. Only installed selections appear in the live status inventory.

shm root-services-status list --pretty
systemctl list-unit-files --type=service --no-pager
systemctl list-unit-files "postgresql*.service" --no-pager

Use the service key with SHM and the unit name with systemd. For example, SHM reports apache while systemd controls httpd.service; SHM reports mail while systemd controls exim.service.

Companion applications

Use one application at a time. A healthy database or mail daemon does not prove its browser application is healthy, and the reverse is also true.

systemctl status roundcube.service --no-pager -l
systemctl restart roundcube.service
journalctl -u roundcube.service --since "-10 minutes" --no-pager
tail -n 100 /opt/shm/logs/roundcube/error.log

systemctl status phpmyadmin.service --no-pager -l
systemctl restart phpmyadmin.service
journalctl -u phpmyadmin.service --since "-10 minutes" --no-pager
tail -n 100 /opt/shm/logs/phpmyadmin/error.log

systemctl status pgadmin.service --no-pager -l
systemctl restart pgadmin.service
journalctl -u pgadmin.service --since "-10 minutes" --no-pager
tail -n 100 /opt/shm/pgadmin/logs/error.log

systemctl status radicale.service --no-pager -l
systemctl restart radicale.service
journalctl -u radicale.service --since "-10 minutes" --no-pager

Per-account PHP

SHM creates versioned account-owned PHP-FPM units in the form exampleuser-php83.service. One account can use more than one PHP version across its domains, so derive the active versions and exact units before acting.

ACCOUNT=exampleuser
shm php-runtime list --account-user="$ACCOUNT" --pretty
shm information list --account-user="$ACCOUNT" --pretty
shm information list --account-user="$ACCOUNT" | jq -r '.result.php_units[]?'

The optional jq line prints only account units currently used by a domain. Use a returned value exactly:

UNIT=exampleuser-php83.service
shm information-php-pools-status create --account-user=exampleuser --data unit="$UNIT" --pretty
shm information-php-pools-action create --account-user=exampleuser --data unit="$UNIT" --data cmd=restart --pretty
shm information-php-pools-status create --account-user=exampleuser --data unit="$UNIT" --pretty

The same root-only operation can be inspected directly through systemd when diagnosing startup or logs:

UNIT=exampleuser-php83.service
systemctl status "$UNIT" --no-pager -l
journalctl -u "$UNIT" --since "-15 minutes" --no-pager
tail -n 100 /var/log/php/exampleuser-php83.error.log
systemctl restart "$UNIT"
systemctl is-active "$UNIT"

Names such as shm-php83-php-fpm.service belong to the shared packaged runtime layer and are not a substitute for an account-owned pool. Restart only the unit returned for the affected account/version, then test the affected domain and check its /var/log/domains/example.com/error.log.

Node.js applications

SHM owns account application metadata and process lifecycle. Discover the project and application id first, then use the scoped action instead of guessing a PM2 process name.

ACCOUNT=exampleuser
shm nodejs-discovery list --account-user="$ACCOUNT" --pretty
shm nodejs-apps list --account-user="$ACCOUNT" --pretty
shm nodejs-apps get --account-user="$ACCOUNT" --id APP_ID --pretty
shm diagnostics-runtime-summary list --account-user="$ACCOUNT" --query domain=example.com --pretty
shm nodejs-apps action --account-user="$ACCOUNT" --id APP_ID restart --pretty
shm nodejs-apps get --account-user="$ACCOUNT" --id APP_ID --pretty

Declared lifecycle actions are start, stop, restart, and repair. Use repair only when the saved application is correct but its managed runtime definition is missing or damaged. The account's Node.js Manager remains the preferred place to create, edit, view logs, or remove an app.

Inspect or maintain the server-wide SHM Node.js runtime catalog separately:

/opt/shm/scripts/runtime-nodejs-install.sh list
/opt/shm/scripts/runtime-nodejs-install.sh available
/opt/shm/scripts/runtime-nodejs-install.sh help

Installing, updating, or removing a runtime version can affect several accounts; those commands are listed under on-demand maintenance below.

Podman and JailShell

Podman and JailShell depend on permissions delegated by the kernel or outer container host. A restart cannot create cgroup v2 controllers, user namespaces, subordinate UID/GID mappings, mount permissions, or /dev/fuse access that the virtualization host has withheld.

/opt/shm/scripts/podman-runtime-prerequisites.sh capabilities
/opt/shm/scripts/podman-runtime-prerequisites.sh host-check
/opt/shm/scripts/jailshell-manager.sh runtime-capabilities
/opt/shm/scripts/jailshell-manager.sh list
/opt/shm/scripts/jailshell-manager.sh preflight-client-refresh

The capability commands are the first check on bare metal, KVM, LXC, OpenVZ, or Virtuozzo. If they report an unavailable host feature, preserve that reason and ask the virtualization provider to delegate it. Independent SHM services can remain healthy even when managed Podman, JailShell mounts, or cgroup-based account limits are unavailable.

For an account whose Podman capability is already available, use SHM's account-scoped actions:

shm podman --account-user=exampleuser dashboard_info --pretty
shm podman --account-user=exampleuser containers_list --pretty
shm podman --account-user=exampleuser container_restart --data name=CONTAINER_NAME --pretty
shm podman --account-user=exampleuser compose_restart --data project=my-app --pretty

Use shm podman --help for the complete action list and required fields. Container names and Compose project names must come from SHM. The Podman Manager is safer for routine container and Compose operations.

Timers and sockets

systemctl list-timers --all "shm-*" --no-pager
systemctl list-sockets --all "shm-*" --no-pager
systemctl status shm-av-scan.timer --no-pager -l
systemctl status shm-jailshell-cleanup.timer --no-pager -l
systemctl status shm-jailshell-restore.timer --no-pager -l
systemctl status "shm-jailshell-podman@exampleuser.socket" --no-pager -l
journalctl -u shm-av-scan.service --since today --no-pager
journalctl -u shm-jailshell-cleanup.service --since today --no-pager

Do not enable an unknown timer merely because it is inactive. Compare its installed unit with the owning SHM feature and saved configuration first.

On-demand tools

Inspection and preview commands. These are the safest entry points. They still require root because they read protected SHM state.

Maintenance commands that change state. Run only after the corresponding inspection, snapshot, and maintenance-window decision.

Run each script's --help or documented help action before a maintenance invocation. Release creation, encryption, bootstrap, migration internals, credential bridges, and QA scripts are deliberately excluded because they are not normal customer-server operations.

How to use it

1. Identify the symptom, exact account/domain, and owning SHM page.
2. Read SHM state with shm, then identify the exact unit, application id, container name, or generated account unit.
3. Capture systemctl status, systemctl show, recent journal entries, and application logs before a lifecycle action.
4. Run a configuration test, capability probe, or --dry-run when available.
5. Snapshot the affected managed configuration and run the narrowest supported reload, restart, or repair.
6. Repeat the original read checks and test the customer-facing website, mail flow, database login, DNS answer, or application route.
7. If the same failure remains, stop repeating restarts. Preserve the command, timestamp, output, journal, and SHM error id for Synconix Support.

Result and next check

A successful operation has three independent proofs: the command exits successfully, the owning unit or SHM object reports the expected state, and the affected customer workflow works. For a timer or oneshot service, a completed inactive service can be correct when its last result is successful.

If a unit remains failed, read its first failing ExecStartPre or runtime message instead of restarting related services blindly. If Podman, JailShell, or resource limits report a missing host capability, no SHM restart can override the outer host; resolve the named virtualization permission first.