mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-10 17:23:04 +03:00
Bitwarden does not react on SIGTERM (v1.13.1 sqlite) #1771
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mkilchhofer on GitHub.
Subject of the issue
At least the sqlite flavor of bitwarden_rs does not react on SIGTERM. I already wondered why evicting kubernetes nodes takes longer when bitwarden_rs runs on this node.
I now determined that the binary
/bitwarden_rsinside the sqlite flavored docker image does not react on a SIGTERM signal.Your environment
Steps to reproduce / Actual behaviour
Terminate the docker Image takes long and the exist status it not 0:
Another attempt to check if the binary handles SIGTERM:
podman start bitwardenrs)podman exec -ti bitwardenrs bash)procpspackageNothing happens, I expect, that bitwarden starts to teardown.
Expected behaviour
Bitwarden_rs binary implements a signal handler and handles SIGTERM correctly
Relevant logs
@mfriedenhagen commented on GitHub:
Hello, when reading https://github.com/Yelp/dumb-init's README it is my understanding that the Linux kernel does not send SIGTERM to PID 1 at all if no explicit handler is implemented. If dumb-init would start bitwarden_rs the standard SIGTERM handler would terminate bitwarden_rs as expected.
@mkilchhofer commented on GitHub:
@mfriedenhagen no, that would not help. An init "system" like you mentioned would help when a main process forks child process(es) and does not control the lifecycle of the childs.
The problem is that the whole
/bitwarden_rsprocess does not catch any signal. There are no childs as I observe in normal operation. Maybe there are childs while creating an sqlite backup.@mkilchhofer commented on GitHub:
Maybe this is due to rocket doesn't implement clean shutdown until now:
@mfriedenhagen commented on GitHub:
Another solution could be to use tiny-init or dumb-init. these are meant as small init replacements and handle signals correctly. See https://github.com/Yelp/dumb-init for a complete explanation.
@dani-garcia commented on GitHub:
Indeed the current version of the rocket web server we use doesn't support any kind of graceful shutdow.
The new async version in development does have the capabilities to do it and I have a separate branch using it: https://github.com/dani-garcia/bitwarden_rs/tree/async
@mkilchhofer commented on GitHub:
The enhancement would be that simple:
@BlackDex commented on GitHub:
Also, i see that you are still using a very old version.
We currently are on v1.18 and not v1.13
@mkilchhofer commented on GitHub:
There are some more things I observed, when I terminate a detached bitwarden conainer which
docker stop:We see here, that the return code is 143. From my java experience it looks like we also need to substract 128 and then we get the real 15 return code which is SIGTERM.
@BlackDex yes I know I used an old version in the comment above. I would like to reproduce this with the same version as the issue was created.
I think we indeed could enhance the shutdown experience by adding dumb-init or tiny-init to the Dockerfile. WDYT @BlackDex and @dani-garcia ?
@BlackDex commented on GitHub:
As stated in the comment from @dani-garcia, this is not yet in the master branch. It is only in the async version, which we will probably release shortly once rocket releases there new version as a stable release so that we know there will be no to minimal breaking changes made. Untill then, run bitwarden_rs using
docker run -dwhich will detach itself, and you can stop it viadocker stop.@mkilchhofer commented on GitHub:
Okay, we can simulate this without building a new container image with podman and docker when starting the container with the option
--init.Indeed this helps stopping the container almost with no "lag":
As you can see, when we Press CTRL+C the container stops.
To prove this we can see the output of
ps -efinside the container while it's running:And without the option, we are unable to stop the container with CTRL+C:
What we do not know is what's going on inside the bitwarden_rs process. It seems that the framework rocket still does not support graceful shutdown in the mainline version.
@BlackDex commented on GitHub:
This issue is solved now for all images.
@mkilchhofer added dumb-init which catches all the kill signals and handles then correctly.