Does not always remove lock file when stopped
dangerman200k opened this issue · 6 comments
I frequently have an issue where rtorrent does not remove its lock file when stopping (running in Docker), meaning that next time it starts I get the "could not lock session directory" error and have to manually remove the lock file and restart the container.
I've just encountered this same issue a couple of days ago too, for the first time.
The lock file contains a hostname, which apparently does not always persist.
podman kill rtorrent (rtorrent is the container's local name) kills the container and leaves behind the lock, which contains the hostname of the container. If you remove the lock file and set a hostname when creating the container, the lock file will have the new hostname and rtorrent will manage it properly.
Please try to test this theory and report back! This had been bugging me for a while.
Processes that are hard killed (by podman kill or otherwise) have no chance to clean up after themselves, so it's generally not advisable unless the process is actually stuck. By default, both podman's and docker's stop commands will give containers 10 seconds to gracefully exit before hard killing it. There is no way for this to be fixed from rTorrent's side, it must be allowed to gracefully exit in order to clean up the lock file.
Well of course, I know what killing means in Linux.
Anyways, in various situations Podman will forcefully terminate the container after ten seconds instead of waiting for it to stop gracefully. But I just did it this way to artificially trigger the problem.
It seems rtorrent can manage the lockfile just fine, but the hostname must be static. If not specified, on docker or podman run commands it seems it generates one on the spot. Makes sense, in hindsight. But rtorrent then thinks it's potentially managing something else's lock file and refuses to operate.
Setting a hostname manually worked for me, so I'm mostly asking to see if it was a fluke.
Well of course, I know what killing means in Linux.
I wasn't responding to you specifically, just trying to provide more context on why this also might happen from a regular docker stop, and why it's not an rtorrent bug. My apologies if it came off otherwise.
It seems rtorrent can manage the lockfile just fine, but the hostname must be static. If not specified, on docker or podman run commands it seems it generates one on the spot. Makes sense, in hindsight. But rtorrent then thinks it's potentially managing something else's lock file and refuses to operate.
Setting a hostname manually worked for me, so I'm mostly asking to see if it was a fluke.
The information rtorrent uses to check if the lockfile belongs to someone else is the hostname and PID (the lock file is in plaintext, you can just cat it to see the data), so if you give your container a static hostname and rtorrent runs as PID 1 (or at least something consistent), rtorrent will consider the lock file stale and just adopt it.
so if you give your container a static hostname and rtorrent runs as PID 1 (or at least something consistent
that's nice, because the file always says +1 at the end. maybe it checks if the PID is an rtorrent process or something.
but then again it also probably has to do with how absurdly minimal the container is. you can't even run sh on it. perhaps it is indeed always PID 1