PelagicDreamer

Hi @fithwum , thank you very much for creating and maintaining this container. While developing some backup scripts for my Unraid server, I noticed that the container always takes 30 seconds to shut down. I am a docker novice so I used ChatGPT 5.6 to help investigate the problem. It came up with the diagnosis and solution below, which seems to work. Please accept my humble apologies for just pasting AI output here. I believe this may improve the package's shutdown behavior and I hope you will find it useful. Please do not feel any obligation to implement it, and thanks again for your work. [This is ChatGPT speaking from here on] Hi — I wanted to report a small shutdown issue I found with the fithwum/foundry_vtt:alpine container. The container starts with: /bin/sh /ftemp/Install_Script.shand the script ultimately launches Foundry with: su foundry -c 'node /foundry/fvtt/resources/app/main.js ...'This leaves the shell as PID 1 and Node as a child. As a result, docker stop -t 30 FoundryVTT does not appear to deliver SIGTERM to Foundry. In my testing it waits the full 30 seconds and then exits with code 137, indicating Docker had to SIGKILL the container. Sending SIGTERM directly to the Node process causes Foundry to shut down immediately and cleanly: Shutting down Foundry Virtual Tabletop server Shut-down success. Goodbye!and the container exits with code 0. One possible minimal fix, since this is an Alpine image, would be to use su-exec for the final privilege drop and exec, e.g. exec su-exec foundry node /foundry/fvtt/resources/app/main.js --dataPath=/foundry/data --ignore-gpu-blacklistwith su-exec added to the image if it isn't already installed. That should leave Node as the container's main process after switching to the foundry user, allowing Docker's SIGTERM to reach Foundry normally.