mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Settings are still lost on shutdown in Linux #929
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#929
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 @aliakhtar on GitHub (Nov 21, 2013).
In Linux, if a shutdown is scheduled via sudo shutdown -P +MM, then sometimes it causes the settings to be lost and reset to default. The next time the program opens, it asks to agree to terms (as if it was the first time the program was run), and all settings are reset to default.
I reported this earlier and was told that it'd be fixed in 3.1.0, I'm now using 3.1.0 but this issue is still occuring.
@wowzaman12 commented on GitHub (Nov 21, 2013):
you're using an old version of qbittorrent, latest stable is 3.1.3, give that a try and see if the problem persists
@aliakhtar commented on GitHub (Nov 21, 2013):
How do I upgrade?
@aliakhtar commented on GitHub (Nov 21, 2013):
Is there a PPA repository?
@bwalsh517 commented on GitHub (Nov 22, 2013):
I just lost my settings after I upgraded from 3.1.2 to 3.1.3. I never saw this issue before.
ppa:hydr0g3n/qbittorrent-stable
Start-Date: 2013-11-20 10:45:27
Commandline: apt-get upgrade
Upgrade: qbittorrent:amd64 (3.1.x-0
4569-20131111ubuntu12.04.1, 3.1.x-04587-20131120ubuntu12.04.1)@aliakhtar commented on GitHub (Nov 22, 2013):
i've upgraded to 3.1.3, i'll post back if the issue occurs again
@aliakhtar commented on GitHub (Nov 23, 2013):
@wowzaman12 I've upgraded to 3.1.3 and this issue just occurred again for me, settings were lost after a sudo shutdown
@sledgehammer999 commented on GitHub (Nov 30, 2013):
What happens if you manually close qbt first and then reboot/shutdown? (I mean really exit through file->exit)
@aliakhtar commented on GitHub (Nov 30, 2013):
@sledgehammer999 I've never had a problem with manually closing qbit and then re-opening it. The issue only appears when sudo shutdown is used while qbit is running.. I'd prefer to keep it running because during idle time, it can continue to seed.
@JSteunou commented on GitHub (Dec 9, 2013):
Same here, sudo shutdown -h to remotely turn off my nas before moving it, and when starting it again losing all my settings.
3.1.3 from the same ppa.
@sledgehammer999 commented on GitHub (Dec 9, 2013):
@JSteunou does it happen if you first manually exit qbt and THEN issue the shutdown command?
@aliakhtar commented on GitHub (Dec 9, 2013):
@sledgehammer999 Since we're both using Linux and have this issue, I can tell you that this doesn't happen on manually exiting the program.
@aliakhtar commented on GitHub (Dec 9, 2013):
@sledgehammer999 Any eta on when this might be fixed? This issue is quite critical.
@sledgehammer999 commented on GitHub (Dec 9, 2013):
possible workaround till I get a proper fix. Before issuing a shutdown, issue a pkill on qbt but do not pass the SIGKILL signal. Pass SIGTERM instead. See if that works. (make a script if it does)
@sledgehammer999 commented on GitHub (Dec 9, 2013):
Or sigquit or sigint. whichever works
@aliakhtar commented on GitHub (Dec 9, 2013):
That doesn't seem like much of a workaround, I could just exit qbit before the shutdown, but I'd like to keep it running and seeding till shutdown.
@sledgehammer999 commented on GitHub (Dec 9, 2013):
oh you put a timeout in you shutdown command... then yes this won't work. But out of curiosity can you tell if SIGTERM works? IIRC correctly this is what is send to processes when the system is shutting down.
@aliakhtar commented on GitHub (Dec 9, 2013):
@sledgehammer999 Yeah I'm issuing a timeout for a scheduled shutdown. Unfortunately my linux skills aren't up to par for sending a sigterm manually. Perhaps you can try it yourself?
@sledgehammer999 commented on GitHub (Dec 9, 2013):
pkill qbittorrent-nox -signal SIGTERMshould work. Try SIGQUIT too.@aliakhtar commented on GitHub (Dec 9, 2013):
pkill: invalid session id: ignal
@sledgehammer999 commented on GitHub (Dec 12, 2013):
sorry the correct usage should be:
pkill qbittorrent-nox --signal SIGTERMpkill qbittorrent-nox --signal SIGQUITPS: SIGKILL is instant death. The process isn't allowed to process anything and it is killed immediately.
@aliakhtar commented on GitHub (Dec 12, 2013):
I've tried all three, sigterm, sigquit, and sigkill. Neither of them killed QbitTorrent, it remains in task bar and I can click it to pull it up.
Anyway, I'm not sure why we're focusing on the symptom rather than the cause here. The problem is, on forced shutdown, QBitTorrent loses its settings. Why is that? Are the settings stored in memory somehow? Or is it because the settings files are getting corrupted on abrupt program shutdown?
@sledgehammer999 commented on GitHub (Dec 12, 2013):
My guess is that qbt doesn't detect correctly system shutdown or it isn't given time to save data.
If you know anything about qt programming we currently only react to commitmessage() of qapplication but I think we must connect to the aboutToQuit signal of qcoreapplication.
These few weeks I don't have time to make any development on qbt. Probably I'll start from the next month.
@aliakhtar commented on GitHub (Dec 12, 2013):
Wouldn't a better fix be to only write the settings when the user makes any changes, but the rest of the time only open them in read only mode? I don't see the reason behind re-saving the settings every program exit. IMO they should be opened in read only mode except when the user makes any changes.
@sledgehammer999 commented on GitHub (Dec 12, 2013):
That's correct. But it is how the current code behaves from the start and it is all over the place. Sadly, I wasn't the original author. It would be difficult to go back and write it from scratch.
@aliakhtar commented on GitHub (Dec 12, 2013):
Damn. Rather than rewriting, couldn't we just change only the code for reading the settings to do so from a read mode rather than write mode?
Also, this behavior is random, it doesn't always occur on forced shutdown, sometimes the settings are not lost, and other times they are.
@sledgehammer999 commented on GitHub (Dec 12, 2013):
The code uses a qt class (qsettings) which abstracts away such things. This means we don't have direct control on when it reads/writes the settings from disk or we misuse the class.
@aliakhtar commented on GitHub (Dec 12, 2013):
Then, sounds like that class alone has to be changed. Or are you saying we can't change it?
@sledgehammer999 commented on GitHub (Dec 12, 2013):
We can't because a lot of code uses it and we will have to review all of that with the new class.
@sledgehammer999 commented on GitHub (Dec 22, 2013):
I pushed a possible fix on git master. Await for this "unstable" PPA to sync with git and build the new version.
(the rev number in the naming should be bigger than 4582)
Unstable PPA: https://launchpad.net/~hydr0g3n/+archive/qbittorrent-trunk/
@sledgehammer999 commented on GitHub (Dec 25, 2013):
Did anyone try this?
@aliakhtar commented on GitHub (Dec 25, 2013):
I'd rather wait till its pushed into the stable ppa, or I would have two conflicting qbittorrent versions, one from unstable and the other from stable.
@sledgehammer999 commented on GitHub (Dec 25, 2013):
I pushed the changes on the v3_1_x branch too. Wait for the ppa to sync.
@aliakhtar commented on GitHub (Dec 25, 2013):
I ran apt-get update but don't yet see any updates.
@JSteunou commented on GitHub (Dec 26, 2013):
As soon as I will see the update I will test it and let you know.
@sledgehammer999 commented on GitHub (Dec 26, 2013):
As of ~6 hours ago the ppa seems updated.
https://launchpad.net/~hydr0g3n/+archive/qbittorrent-stable/
@aliakhtar commented on GitHub (Dec 26, 2013):
i've run the update, but i still see version 3.1.3 when I start the program. Is that expected?
@sledgehammer999 commented on GitHub (Dec 26, 2013):
Yes. I haven't changed the version string. You should look at the rev number and build date eg: 3.1.x-0~4605-20131226 "4605" is the revision number and "20131226" is the build date.
@aliakhtar commented on GitHub (Dec 26, 2013):
where do I check the revision / build?
@sledgehammer999 commented on GitHub (Dec 26, 2013):
https://launchpad.net/~hydr0g3n/+archive/qbittorrent-stable/
@JSteunou commented on GitHub (Dec 26, 2013):
I'm using the 4603 build version and it's good for me. I used
shutdown -r nowto reboot, and when the server was back all the qbittorrent configuration was saved.@sledgehammer999 commented on GitHub (Dec 26, 2013):
IIRC 4603 doesn't contain the fix.
@JSteunou commented on GitHub (Dec 26, 2013):
Sorry I missread:
3.1.x-0
4605-20131226ubuntu12.04.1@aliakhtar commented on GitHub (Dec 26, 2013):
I didn't look at the build etc when I was updating, but I did update, so I've probably got the right version. Is there no way to check the revision / build from within the program?
I wouldn't be too quick to declare that the program is fixed, because this issue is intermittent, often it would work fine for 9-10 reboots and on the 11th reboot, the issue would occur. I'd give it a week to test it.
@JSteunou commented on GitHub (Dec 26, 2013):
try
dpkg -l | grep qbittorrentAlso I just checked with one reboot only. But last time the bug occurred with one reboot only though...
@aliakhtar commented on GitHub (Dec 26, 2013):
I see
dpkg -l | grep qbittorrent ii qbittorrent 3.1.x-0~4605-20131226~ubuntu12.10.1 i386 bittorrent client based on libtorrent-rasterbar with a Qt4 GUIis that correct?
@JSteunou commented on GitHub (Dec 26, 2013):
Yep. Now you can reboot again & again to test it. If it works for you like for me I guess we should congrats @sledgehammer999 and call this closed.
@sledgehammer999 commented on GitHub (Dec 26, 2013):
I'll leave another 24h open and then I'll close it. Probably I'll push a v3.1.4 release just for this.
I just hope noone has this problem again during the 24h period.
Also the people from the Windows front haven't confirmed anything(see other related bugs under the v3.1.4 milestone)
@aliakhtar commented on GitHub (Dec 26, 2013):
All right, if the issue occurs again, will we be able to post again here and get your attention?
P.S thanks for your help!
@sledgehammer999 commented on GitHub (Dec 26, 2013):
Yes, and no problem.
@JSteunou commented on GitHub (Dec 26, 2013):
3 others shutdown here (rude storm) still no issue again. Thanks @sledgehammer999
@sledgehammer999 commented on GitHub (Dec 26, 2013):
Take note: If the pc shutdowns abruptly due to a system crash or a power failure, there's possibility for the settings to still get lost and I can't do anything about it.
@JSteunou commented on GitHub (Jan 5, 2014):
I'm sorry to tell you that I still have the issue. I did a
shutdown -r nowafter a security update and qbittorrent relaunch without settings :(@sledgehammer999 commented on GitHub (Jan 5, 2014):
Wait for the PPA stable to update and use the newest version there(according to the rev number). I have pushed some more possible fixes in git.
@JSteunou commented on GitHub (Jan 5, 2014):
Ok. I was in 4605, now I'm in 4621. I'll tell you again if I still have this bug.
@sledgehammer999 commented on GitHub (Jan 5, 2014):
4621 contains some fixes but you should update to >4621 after the ppa builds again. (probably in a couple of hours)
@kevincox commented on GitHub (Jan 11, 2014):
I had this problem too. It used to happen quite frequently but it happened this morning for the first time in a while.
I am using v3.1.4 (pi version :D ) on Arch Linux.
If there is any more info I can give please let me know.
@aliakhtar commented on GitHub (Jan 21, 2014):
I'm using 3.1.5 and just had this issue occur for me again. For a while, since my last comment about a month ago, I didn't have this issue occur, but it did occur last night again when I did a shutdown -P +60.
@kevincox commented on GitHub (Jan 21, 2014):
I would like to add that this has started to happen most times I shut down
my computer recently.