When deploying this docker image
lscr.io/linuxserver/grocy:amd64-latest. I get the following error
Main child exited normally with code: 100. When I build and run the image locally everything works so I am not sure what the problem is or how to diagnose / move forward. Any help would be appreciated.
app = "grocy"
kill_signal = "SIGINT"
kill_timeout = 5
processes = 
image = "lscr.io/linuxserver/grocy:amd64-latest"
allowed_public_ports = 
auto_rollback = true
http_checks = 
internal_port = 80
processes = ["app"]
protocol = "tcp"
script_checks = 
hard_limit = 25
soft_limit = 20
type = "connections"
force_https = true
handlers = ["http"]
port = 80
handlers = ["tls", "http"]
port = 443
grace_period = "30s"
interval = "60s"
restart_limit = 0
timeout = "10s"
2022-08-03T16:59:25Z [info]Pulling container image
2022-08-03T16:59:25Z [info]Unpacking image
2022-08-03T16:59:25Z [info]Preparing kernel init
2022-08-03T16:59:25Z [info]Setting up volume 'grocy_data'
2022-08-03T16:59:25Z [info]Opening encrypted volume
2022-08-03T16:59:26Z [info]Configuring firecracker
2022-08-03T16:59:26Z [info]Starting virtual machine
2022-08-03T16:59:26Z [info]Starting init (commit: c86b3dc)...
2022-08-03T16:59:26Z [info]Mounting /dev/vdc at /config w/ uid: 0, gid: 0 and chmod 0755
2022-08-03T16:59:26Z [info]Preparing to run: `/init /bin/sh -c echo "starting"` as root
2022-08-03T16:59:26Z [info]2022/08/03 12:59:26 listening on [fdaa:0:7cf6:a7b:ab3:1:605d:2]:22 (DNS: [fdaa::3]:53)
2022-08-03T16:59:27Z [info]Main child exited normally with code: 100
2022-08-03T16:59:27Z [info]Starting clean up.
2022-08-03T16:59:27Z [info]Umounting /dev/vdc from /config
I’d say at least 50% of the requests on this forum are due to ipv6 not being used on the application level.
So I’d start by making sure that grocy is listening on ipv6. If that doesn’t work, you’ll need the app to stay up while you login and debug. For that you’ll need to take out the service checks, or maybe just run nginx or something so that you can do
fly ssh console to be able to login and debug.
I don’t know much about docker and nginx so I’m not sure how to verify that its listening on ipv6. Is removing the checks as simple as changing the relevant config to
http_checks = 
I think you can remove the entire services section and have the image be deployed and not be reaped. I did do this at one point, but do not recall exactly how I fiddled with it.
Regarding ipv6, you will need to
fly ssh console and
lsof -ni and make sure the process is listening on the port you expect.
# lsof -ni|grep LISTEN
epmd 563 nobody 3u IPv4 4451 0t0 TCP *:4369 (LISTEN)
epmd 563 nobody 4u IPv6 4452 0t0 TCP *:4369 (LISTEN)
Just quickly ran the image, but i got to get off the computer. Error may be unrelated to ipv6.
2022-08-04T00:01:52Z app[95d1dfe5] sea [info]2022/08/04 00:01:52 listening on [fdaa:0:2fff:a
2022-08-04T00:01:52Z app[95d1dfe5] sea [info]s6-overlay-suexec: fatal: can only run as pid 1
2022-08-04T00:01:53Z app[95d1dfe5] sea [info]Main child exited normally with code: 100
After some digging around I think I know what the issue is! Thanks to your last message with the error
s6-overlay-suexec: fatal: can only run as pid 1 I was able to do some digging and found that the image I’m using, uses a process manager that wants to run as pid 1 which, according to Running Multiple Processes Inside A Fly.io App · Fly Docs, isn’t possible.
How were you able to get those logs?
I’m assuming you’re referring to the line about s6 init? Mostly luck. It restarted a few times and I noticed this one extra errant line about s6 which did not print on most of the runs.
Well thanks, anyway. Without that I wouldn’t have know what the issue was.