valnesfjord/tg-ws-proxy-rs v2.5.2

tg-ws-proxy-rs v2.5.2

on GitHub

A proxy that cannot start now says why, and the installer says it after about a second instead of fifteen.

Why

start() in the Entware init script launched the proxy with >/dev/null 2>&1 and, on failure, printed
the last lines of the log file. The bind error is written to stderr before any logging exists, so it was
discarded, and rotate_log had already moved the previous log aside — on a port held by another process
the user saw:

Starting TG WS Proxy (Rust)...             failed.
Last log lines from /opt/var/log/tg-ws-proxy-rs.log:

Measured on a Keenetic (MT7621, kernel 4.9, the port held by another process): the binary itself reports
cannot bind 0.0.0.0:1443: Address in use (os error 125) and exits 1, and none of it reached the log or
the console. The installer was no better: entware_wait_ready polls for 15 seconds and then reports
service did not become ready (see …), which also names no cause.

Fixed

• The proxy's stderr goes to the log file instead of /dev/null (when the log directory exists), so
  the reason — a bind that lost the port, a listen address the kernel refuses, a config it cannot read —
  is in the tail both the init script and the installer print. With TG_LOG_FILE set the binary writes
  its tracing to that file and keeps stderr for exactly these pre-logging errors.
• The installer stops waiting once the process is gone: entware_wait_ready returns as soon as
  pidof tg-ws-proxy-rs is empty, so a start that fails is reported when it fails, not after 15 seconds
  of polling a process that no longer exists.
• The installer prints the reason before rolling back: the service did not become ready message now
  carries the last lines of the log. They are read before rollback_entware, which starts the previous
  service again and whose start() rotates this log to .log.1.

Notes

• Neither place pre-checks the port. A listener found before the launch can be this build's own previous
  instance — started by hand, or with the init script disabled by chmod -x, which is the documented way
  to turn it off — and a listener on another address, or the other IP family, would not stop the bind at
  all. The bind decides, and what it writes is now in front of the user.
• The OpenWrt path is unchanged: procd captures both streams into logd (procd_set_param stdout 1 /
  stderr 1), so cannot bind … is already visible there with logread -e tg-ws-proxy-rs.