apply_configs does not reliably start hiddify-dnstt-<domain>.service; stale-unit cleanup broken by "rm -rf svc" typo in run.sh.j2; no disable.sh shipped

Describe the bug

After apply_configs completes with a DNSTT domain configured, the unit file hiddify-dnstt-<domain>.service is generated and rendered, but the service is not active. Starting it manually (bash other/dnstt/run.sh) works — the unit itself is fine.

Root cause (three separate defects)

a) Background launch. install.sh (~line 85) runs the DNSTT setup step in the background:

install_run other/dnstt $(hconfig "dnstt_enable") &

When this step doesn't complete (see also the cli_progress hang reports), no later stage of apply verifies the service state, so the failure is silent.

b) Typo in other/dnstt/run.sh.j2 (first lines of the template):

for svc in hiddify-dnstt-*.service; do
    systemctl stop "$svc"
    rm -rf svc      # <- should be "$svc"; currently removes a file named "svc"
done

The stale-unit cleanup therefore never works. One-character upstream fix.

c) Missing disable.sh. runsh() in install.sh switches the command to disable.sh when the third argument is false/0 — but no disable.sh exists in other/dnstt/. Result: setting dnstt_enable=false and re-applying silently does nothing; the DNSTT service keeps running. (Related to the "can't disable components" class of reports, e.g. #5015 for relay proxies.)

To Reproduce

1. Fresh 12.3.3 install, add a domain with mode dnstt, run apply_configs.
2. After completion: systemctl status hiddify-dnstt-<domain>.service — unit file exists, service inactive.
3. bash other/dnstt/run.sh → service starts and works.
4. For (c): set dnstt_enable=false, re-apply, observe the service still running with no error anywhere.

Expected behavior

• apply_configs leaves every rendered service in the state the config implies (running if enabled).
• The stale-unit cleanup loop actually removes old units.
• Disabling DNSTT stops and disables its services (or apply fails loudly when the disable script is missing).

Environment

• Hiddify Manager: 12.3.3
• OS: Ubuntu 24.04, kernel 6.8

Suggested fixes

1. Run the DNSTT step in the foreground, or add an end-of-apply check: systemctl is-active hiddify-dnstt-* with a warning on failure.
2. rm -rf svc → rm -rf "$svc" in run.sh.j2.
3. Ship a disable.sh for other/dnstt (stop + disable the units), or make runsh() fail loudly when the disable script is absent.

Workaround for users

After every apply, run manually (idempotent — re-renders the unit and restarts the service):

bash /opt/hiddify-manager/other/dnstt/run.sh

Related

• #5530 (Bug Report Package) — its Issue A analyzes install_run/DO_NOT_INSTALL for newly-enabled components; this report is the DNSTT-specific neighbor of that problem (step backgrounds + no post-check).
• #5363 — same DNSTT feature, subscription-side defect.