mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Shutting down QBittorrent + WebUI setup from systemctl can cause data loss #11371
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#11371
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @flying-sausages on GitHub (Dec 6, 2020).
Sorry about not having all the information requested here, but I'm working off of a sparse downstream ticket. https://github.com/swizzin/swizzin/issues/503
Please provide the following information
qBittorrent version and Operating System
Sadly, unknown, per context above
If on linux, libtorrent-rasterbar and Qt version
Sadly, unknown, per context above
What is the problem
Shutting down qbittorrent through the suggested systemd can cause data loss
What is the expected behavior
A way to gracefully shut down the process without causing data loss. I would assume that this might be done through a specific termination signal maybe but I cannot find any info on this. Either way, the default
systemctl stopbehaviour without a specific action is to send aSIGTERM, which does not seem to be handled properly in the setup described below.It would be great to know whether there's a way to specify an
ExecStop=or similar which would take care of this case.Steps to reproduce
Follow this guide in the wiki and then run
systemctl stop qbittorrentwith active torrents loaded in qbittorrent.Systemctlwill shut down the process ungracefullyExtra info(if any)
N/A
@flying-sausages commented on GitHub (Dec 6, 2020):
I found some references to this elsewhere but no answers yet
@FranciscoPombal commented on GitHub (Dec 6, 2020):
Thanks for the report.
The systemd default is to send
SIGTERM, even ifExecStopis not specified, like you said. As pergithub.com/qbittorrent/qBittorrent@3485ad39d9/src/app/main.cpp (L299), bothSIGTERMandSIGINTare handled, and this is working correctly as far as I know.Regardless, I have edited the wiki page in question to more closely match what I am using in one of my "production" machines. I chose
SIGINTinstead of the default, for consistency with termination from the shell (^CsendsSIGINT), but this is purely an aesthetic decision AFAIK.Perhaps there is some bug in the signal handling logic that I haven't been able to observe so far. @an0n666 can you reproduce it?
@flying-sausages commented on GitHub (Dec 6, 2020):
Just to clear out any doubts, here is the service file we are currently using
@ghost commented on GitHub (Dec 6, 2020):
The process getting killed instantly when systemctl issues a stop command is reproducible.
However, after some investigation I found out the actual reason for the data loss:
My disk ran out of space. I cleaned out 150 GiB+ while qBt was still running.
In the meantime, qBt failed to write any fastresume data and zero-filled almost 300+ files(this I found out later when I went to check the BT_Backup after the data loss)
After making space I stopped the service to reboot my server.
But since the process was just insta killed qBt missed the opportunity to rewrite those zero-filled fastresume files during the shutdown process.
Additional issues: When I went to check the BT_backup folder I found 300+ fastresume files were only 0 byte. Then I had to delete those fastresume files because qBt won't even allow re-adding those torrents
since it even loads empty fastresume files to session!@FranciscoPombal commented on GitHub (Dec 7, 2020):
This definitely isn't supposed to happen. Any chance you can figure out what's wrong? Is there some kind of problem catching SIGINT or SIGTERM, or both?
@ghost commented on GitHub (Dec 7, 2020):
First I tried with the updated wiki and it was killing the process instantly.
After some trial and error, I found that this line was causing the issue
KillSignal=SIGINTAfter removing it the process was gracefully killed.
Here's the final systemd unit file.
Note to swizzin devs: the process doesn't run as a daemon and there's no forking. So I suggest you to change the Type=simple and remove -d from the ExecStart.
@Chocobo1 commented on GitHub (Dec 7, 2020):
We have an official .service file here: https://github.com/qbittorrent/qBittorrent/blob/master/dist/unix/systemd/qbittorrent-nox%40.service.in
@an0n666
Do you confirm that this line makes all the differences?
ExecStop=/usr/bin/pkill --signal SIGINT qbittorrent-noxIf that is true, can you submit a patch?
ps. note that I would expect that qbt is identified by pid when sending the signal.
pps. If possible, I would expect sending
SIGTERMinstead ofSIGINT.ppps. Could be something like:
ExecStop=/usr/bin/kill $MAINPID@ghost commented on GitHub (Dec 7, 2020):
Ok so I just removed that line as well and it's working fine. Just changing these were enough:
So the script in the wiki(previous revision) would've worked just fine. idk why swizzin changed the type to forking.
You can close this.
@liaralabs commented on GitHub (Dec 8, 2020):
If this is true, then that means the daemon mode isn't gracefully handling the SIGTERM signal and instantly closing qbittorrent as you claim.
The script is forking because a daemon process forks off the main PID, and this setting informs systemd of that so that it monitors the child PID instead.
I can't recall why I chose daemon mode though -- it may have been to avoid potential issues with accepting the legal agreement and scripting, which I can't recall if I actually tested, to be fair.
@userdocs commented on GitHub (Dec 8, 2020):
@FranciscoPombal there are also
--usersystemd services in~/.config/systemd/user. I use this.@FranciscoPombal commented on GitHub (Dec 8, 2020):
After some experimentation, it does seem like using SIGINT is flakier, though it seemed spurious and I'm not sure why, haven't looked into it. I have edited the wiki page to improve the service file.
It now boils down to this:
This uses the systemd defaults for terminating the process (SIGTERM). This is pretty much the same as our "offiicial" bundled script now, except that the
Typeis exec (which is better than simple for our use case in systems with recent enough systemd to support this type), and also it does not specifyPrivateTmp=false, which is the default anyway, so it really does not need to be there.I can confirm that this config works well (qBittorrent exits gracefully), whether stopping qBittorrent via systemd or via its own menu in the WebUI.
@liaralabs
With the configuration in this post, you don't need daemon mode (the
-dflag), in fact, it would not even be correct and could potentially be a source of problems.@userdocs
A user service is also a good idea. If you want, you could contribute a wiki page with that information, or add it to the existing one as an alternative.