enable-reload-signal option causes crash

[mizuguta]

Hello,
I am using mbtileserver and need to reload tilesets because of changes of sub directories containing mbtile files.
Unfortunately I didn't succeed to reload by HUP signal, it always abnormally exists.

~/go/bin/mbtileserver --enable-reload-signal -d ./data --root-url /tile_service
INFO[0000] Searching for tilesets in ./data             
INFO[0000] Published 37 services                        

--------------------------------------
Use Ctrl-C to exit the server
--------------------------------------
HTTP server started on 0.0.0.0:7777

Then I send HUP signal to the process:

kill -HUP xxxx

It causes abnormal exist:

Reloading...

EXITING (abnormal child exit: wait: no child processes)

It happens on Docker with image golang:latest.
How can I make it working?

Thanks!

[brendan-ward]

Thanks for the report. To clarify, are you building your own Docker image based on golang:latest or are you using one of the existing mbtileserver images?

[mizuguta]

Hello @brendan-ward and thank you for responding back to me.
The issue happens in all following cases on my end:

1. Use the existing mbtileserver image, by using docker-compose.yaml in the repository.

2. Build my own image based on golang:latest, i.e.

FROM golang:latest
RUN go install github.com/consbio/mbtileserver@latest

3. Start mbtileserver on command line and send HUP to the process, i.e.

~/go/bin/mbtileserver --enable-reload-signal -d ./data --root-url /tile_service
kill -HUP <pid of mbtileserver above>

Please let me know if any further information is needed.

[brendan-ward]

I can reproduce in the latest version. This is not a feature I personally use, so I'm not very familiar with it. I am seeing that when passing --enable-reload-signal that there are 2 processes created in the docker container:

I'm not sure if it always showed up as 2 processes when started this way. Calling kill -HUP 1 causes the error, whereas calling kill -HUP 12 appears to cause reloading to work properly. @nikmolnar is this expected behavior? If so, what can we add to our docs to make this more clear?

[mizuguta]

@brendan-ward
Thank you for the information.
Sending HUP to the second process would be a good workaround, which worked on my end as well.