Small bug in agate+ start.sh, tmpfs wipes /tmp/proxy/ on restart
TL;DR: /tmp is tmpfs on Cloudron, so /tmp/proxy/*.sh vanishes on every restart. Line 52 cp fails, set -e kills start.sh before supervisord launches, nothing binds :8000, healthcheck loops forever. Wrap the cp block in if [ -f /tmp/proxy/restart-proxy.sh ]; then ... fi.
Hi @timconsidine! We ran into a restart loop on agate+ today and wanted to flag the cause in case others hit it too.
Symptoms in the app logs:
cp: cannot stat '/tmp/proxy/restart-proxy.sh': No such file or directory
=> Healthcheck error: Error: connect EHOSTUNREACH 172.18.x.x:8000
What's happening
In normal run mode on Cloudron, /tmp is backed by a fresh tmpfs on every container start, which shadows the /tmp/proxy/ files baked into the image. So the cp on line 52 of start.sh fails, set -e aborts the script, and exec supervisord on line 154 never runs. healthcheck.js never binds port 8000, Cloudron healthcheck fails, container gets restarted — and round it goes forever.
The copied files already exist in /app/data/ from the first install anyway, so the cp is really only needed on fresh installs.
(In debug mode the tmpfs overlay isn't applied, so the files are visible and the app starts fine, which made it a bit confusing to diagnose at first.)
Suggested fix
Guard the proxy-file copy block so it's a no-op when the source isn't there:
if [ -f /tmp/proxy/restart-proxy.sh ]; then
cp /tmp/proxy/restart-proxy.sh /app/data/restart-proxy.sh
cp /tmp/proxy/register-new-instance.sh /app/data/register-new-instance.sh
cp /tmp/proxy/deregister-instance.sh /app/data/deregister-instance.sh
chmod +x /app/data/register-new-instance.sh /app/data/deregister-instance.sh /app/data/restart-proxy.sh
fi
Alternatively, stage those helpers somewhere persistent (e.g. ship them in /app/code/proxy/ and copy from there) so they survive the tmpfs reset on every restart, not just on fresh installs.
Tested the guarded version on our instance and it's back up and running cleanly. Happy to open an MR if useful.
