tobychui
Zoraxy Docker, Statistics of actual day is lost when reboot
Is your feature request related to a problem? Please describe. I run Zoraxy in a Docker container. When I restart the container or reboot the machine, the current day's stats are lost. I can use the data selector to get the previous day's stats. However, the current day's stats are lost forever. The logs look good. I can see everything from the whole day.
Describe the solution you'd like Where does Zoraxy store the stats? It seems that the day's stats are moved to a different location when the day changes. Would it be possible to store the stats in a permanent location (Docker volume)?
Describe alternatives you've considered
Additional context Since settings and logs are available even after rebuilding the Docker container, I assume that the persistent volume configuration is generally OK.
@DonniDoc Zoraxy store the stats when it receive a interrupt signal, well except the uptime monitor data, your stats shd be stored in the sys.db database.
Thank you soo much for your assistance. Well... I'm running Proxmox as hypervisor. The VM uses debian 12 and docker. Qemu-guest-agent is running as well. Means restarts are coordinated. Since the problem occurs even when just restarting the Zoraxy Docker container, I assume that the host OS (Proxmox -> Debian) has nothing to do with it. Is there an option/environment variable that makes Docker send a term signal and wait some time before shutting down? It seems to me that Docker shuts down the container immediately and does not wait for any pending writes. Or would docker wait and maybe zoraxy does not report that there are any pending writes?
Hmmm, ok, I thought this has been fixed.
@PassiveLemon would you mind take a look at this? Thanks!
I played around a bit with SIGTERM and SIGINT. Docker sends SIGTERM by default. But also --stop-signal SIGINT does not change anything. --timeout -1 does not help eather. Then there is no shutdown at all. It seems zoraxy does not react to the signals. It always ends with the final SIGKILL which at least explains the loss of the stats.
@DonniDoc I am not good at tinkering with docker, but maybe you can find a way to send Ctrl + C into Zoraxy STDIN?
The Docker container exits immediately because the sigterm is sent to Zoraxy and ZeroTier, both of which react to it and shut down (You can see Zoraxy doing stuff after receiving it). If they didn't, then it would take 10 seconds before Docker sends the sigkill which then forcefully kills the container. As far as I can tell, there's nothing wrong with the signals
@DonniDoc I am not good at tinkering with docker, but maybe you can find a way to send Ctrl + C into Zoraxy STDIN?
You can run the container interactively (stdin: true and tty: true for compose or -it for docker run), but due to a recent refactor, Zoraxy is no longer the exec'd process so I think you would just be ctrl-c'ing the bash process which would process the signals in the exact same way it does when sent from Docker
For me there does not seem to be a solution. Zoraxy simly does not react to any term signal coming from docker. Interactive or not. The stats of the day get lost on a restart.
@DonniDoc Well technically I am not sure if it fixed the issue (I have added another signal capture to the shutdown sequence initiator, but depending on the OS / env, it might work or it might not work). If it still didn't work, please tag me to reopen this issue.
I will test with docker standard XTERM and the Option "--stop-signal SIGINT" and let you know as soon as the new docker image is available.
Tested with v.3.1.9. But no change. Independent from stop signal type. With a restart of the docker container you loose the stats. I will probably switch to an LXC and everything should be fine.
Hi, just one thought. Would it make sense to have a function that regenerates the statistics from the logs. Overall, I regret that statistics and logs seem to be so separate. If I could, I would make it so that the statistics are always connected to the logs. Clicking on a line in the statistics would open the corresponding lines in the log. OK, that might be too ambitious. But the idea itself is something, isn't it?
@DonniDoc Log only store a small part of the incoming request information. Statistic store the processed information of the raw request. Currently it is not possible to rebuild statistic from log, but as usual, PR are always welcomed 👍🏻