This is what i was able to figure out based on your provided info. I hope this helps, I’d be frustrated if i was dealing with the same issue. But I’m also not using docker. The unit itself is fine; systemd is just timing out while AMP is busy pulling and starting the Docker image, then killing it with SIGTERM (exit status 143). [1][2]
## What the status output means
- `status=143` is exit code 143, which is $$128 + 15$$, meaning the process died from signal 15 (SIGTERM). [1][2]
- `ampinstmgr.service: start operation timed out. Terminating.` shows systemd hit its start timeout and sent SIGTERM to ampinstmgr, so systemd marks the service as failed even though AMP itself was still working (pulling `wine-stable` etc.). [2]
- The log line `wine-stable: Pulling from cubecoders/ampbase` followed by `Pulling fs layer` suggests a slow Docker pull, often due to network or registry slowness. [3]
## Quick checks to run
On the gameserver, as root or with sudo:
1. Check AMP directly, bypassing systemd
-
`su - amp`
-
`/opt/cubecoders/amp/ampinstmgr start`
-
See if it completes, or hangs at the same “Pulling fs layer” point. This tells you if it’s an AMP/Docker issue vs systemd only.
2. Test Docker pull manually
-
`docker pull cubecoders/ampbase:latest`
-
If this is slow or stuck, you have a Docker/network issue (bandwidth, DNS, firewall, or rate‑limit).
3. Check for resource bottlenecks
-
While starting AMP: `htop` / `top`, and `df -h` for disk space.
-
Slow disk or full filesystem will make Docker pulls crawl.
## Systemd-side fixes
If the only problem is that the pull takes longer than systemd’s default timeout, extend it:
1. Edit the unit override:
```bash
sudo systemctl edit ampinstmgr
```
2. Put something like:
```ini
[Service]
TimeoutStartSec=600
```
3. Reload and restart:
```bash
sudo systemctl daemon-reload
sudo systemctl restart ampinstmgr
```
Now systemd will allow up to 10 minutes for AMP to start before killing it.
## If Docker pull keeps hanging
If the `docker pull` itself is intermittently stuck on “Pulling fs layer”:
- Check routing/DNS (e.g., try `ping hub.docker.com`, `curl https://registry-1.docker.io/v2/`). [3][4]
- Temporarily try a different network/MTU (common with VPSs and tunnels). [3]
- If using a proxy or firewall, ensure Docker can reach Docker Hub.
Once a manual `docker pull cubecoders/ampbase:latest` completes quickly, restarting `ampinstmgr` via systemd should stop timing out.
Citations:
[1] Systemd Exit Status 143 · Issue #4121 - GitHub Systemd Exit Status 143 · Issue #4121 · traccar/traccar · GitHub
[2] unit falling into a failed state (status=143) when stopping service https://stackoverflow.com/questions/45953678/unit-falling-into-a-failed-state-status-143-when-stopping-service
[3] Docker Compose stuck downloading or pulling fs layer [closed] https://stackoverflow.com/questions/38087027/docker-compose-stuck-downloading-or-pulling-fs-layer
[4] Docker Pull Error response from daemon i/o timeout Docker Pull Error response from daemon i/o timeout - Docker Engine - Docker Community Forums
[5] ADS unable to make Instance start on boot · Issue #125 - GitHub ADS unable to make Instance start on boot · Issue #125 · CubeCoders/AMP · GitHub
[6] AMP seems dead on my server - CubeCoders Support AMP seems dead on my server
[7] How to Resolve Docker Image Stuck at Pulling FS Layer Issue https://www.youtube.com/watch?v=s3_4uAXiGgs
[8] AMP crashes out on the backend and it causes all instances to stop AMP crashes out on the backend and it causes all instances to stop
[9] Does anyone else needs to use SuccessExitStatus=143 with systemd? Does anyone else needs to use SuccessExitStatus=143 with systemd? - Help and Support - rclone forum
[10] AMP Timeout: Rebind to Public IPv4 - CubeCoders Support AMP Timeout: Rebind to Public IPv4