Daemon-Autostart auf der TBox (fota.sh) nach dem Deploy #1

Open
opened 2026-08-31 16:31:57 +02:00 by claudecode · 1 comment
Collaborator

Nach dem Aufspielen wird aichi_daemon nur abgelegt + ausfuehrbar gemacht, aber nicht automatisch gestartet. Idempotenten Autostart-Block in fota.sh einhaengen (siehe tbox_daemon-README), per FTP read-modify-write. Danach ueberlebt der Start Reboots.

Nach dem Aufspielen wird `aichi_daemon` nur abgelegt + ausfuehrbar gemacht, aber nicht automatisch gestartet. Idempotenten Autostart-Block in `fota.sh` einhaengen (siehe tbox_daemon-README), per FTP read-modify-write. Danach ueberlebt der Start Reboots.
Author
Collaborator

Hardware-Befund (am echten Fahrzeug getestet): Die TBox-FTP (busybox) kann kein SITE CHMOD (500 Unknown command). Damit macht MiniFtp.siteChmod(...) in der App den Daemon nicht ausführbar — der Autostart-[ -x ... ]-Test würde fehlschlagen und der Daemon nie starten.

Lösung (in diesem Issue mit umsetzen): Das chmod gehört in den fota.sh-Autostart-Block (läuft beim Boot auf der Box, unabhängig von FTP). Der Block soll idempotent angehängt werden und lauten:

# --- tbox_daemon autostart ---
chmod +x /usrdata/tbox_daemon 2>/dev/null
if [ -x /usrdata/tbox_daemon ] && ! pgrep -f /usrdata/tbox_daemon >/dev/null 2>&1; then
    /usrdata/tbox_daemon --cutoff 70 --interval 20 >/usrdata/tbox_daemon.log 2>&1 &
fi
# --- ende ---

Konsequenzen für die App:

  • MiniFtp.siteChmod bleibt best-effort (schadet nicht), ist aber auf dieser Box wirkungslos — der chmod +x im fota-Block ist der verlässliche Weg.
  • Die App muss den fota.sh-Block idempotent anhängen (per FTP read-modify-write oder über den Shell-Kanal), nur wenn der Marker tbox_daemon autostart noch fehlt.
  • Deploy sicher gegen „Text file busy" bei laufendem Daemon: neue Binary als tbox_daemon.new hochladen und per FTP-RNFR/RNTO überschreiben (Referenz-Umsetzung in aiways/tbox_daemon, scripts/provision_tbox.py--safe-update).

Referenz für den kompletten, am Auto verifizierten Ablauf (FTP-Deploy + chmod-über-Shell + fota-Autostart + Reboot): scripts/provision_tbox.py im tbox_daemon-Repo.

**Hardware-Befund (am echten Fahrzeug getestet):** Die TBox-FTP (busybox) **kann kein `SITE CHMOD`** (`500 Unknown command`). Damit macht `MiniFtp.siteChmod(...)` in der App den Daemon **nicht** ausführbar — der Autostart-`[ -x ... ]`-Test würde fehlschlagen und der Daemon nie starten. **Lösung (in diesem Issue mit umsetzen):** Das `chmod` gehört in den fota.sh-Autostart-Block (läuft beim Boot auf der Box, unabhängig von FTP). Der Block soll idempotent angehängt werden und lauten: ```sh # --- tbox_daemon autostart --- chmod +x /usrdata/tbox_daemon 2>/dev/null if [ -x /usrdata/tbox_daemon ] && ! pgrep -f /usrdata/tbox_daemon >/dev/null 2>&1; then /usrdata/tbox_daemon --cutoff 70 --interval 20 >/usrdata/tbox_daemon.log 2>&1 & fi # --- ende --- ``` **Konsequenzen für die App:** - `MiniFtp.siteChmod` bleibt best-effort (schadet nicht), ist aber auf dieser Box wirkungslos — der `chmod +x` im fota-Block ist der verlässliche Weg. - Die App muss den fota.sh-Block **idempotent anhängen** (per FTP read-modify-write oder über den Shell-Kanal), nur wenn der Marker `tbox_daemon autostart` noch fehlt. - Deploy sicher gegen „Text file busy" bei laufendem Daemon: neue Binary als `tbox_daemon.new` hochladen und per FTP-`RNFR/RNTO` überschreiben (Referenz-Umsetzung in `aiways/tbox_daemon`, `scripts/provision_tbox.py` — `--safe-update`). Referenz für den kompletten, am Auto verifizierten Ablauf (FTP-Deploy + chmod-über-Shell + fota-Autostart + Reboot): `scripts/provision_tbox.py` im tbox_daemon-Repo.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
aiways/HeadUnit_TBox_Provisioning#1
No description provided.