Created attachment 842696 [details] Global preferences configuration file Description of problem: I've been using BOINC under Fedora/RHEL for some years now. I have an account at BAM which holds my boinc execution preferences. Every time I setup a new computer I install boinc-client and boinc-manager, setup boinc-client service to be automatically started, and, through boinc-manager, configure boinc to run based on my execution preferences (usually after computer is idle for 1 minute with no other restrictions). When I followed all these steps on Fedora 20 with GNOME 3, even though boinc-client is running, its status is always shown as "suspended - computer is in use", even when the computer is left alone for a whole night doing nothing. I read somewhere on the internet that boinc-client sometimes have issues to identify when a computer is idle. As it is the first time I am using boinc with GNOME 3, I thought that might be the case. They suggested executing "xhost local:boinc" in order to allow boinc user to access X. That didn't help. I have no clue on what should be happening, so I wonder whether boinc-client has any issue with detecting computer activity in GNOME 3. Version-Release number of selected component (if applicable): boinc-manager-7.2.33-2.git1994cc8.fc20.x86_64 boinc-client-7.2.33-2.git1994cc8.fc20.x86_64 How reproducible: Always Actual results: boinc-client never runs BOINC applications. Expected results: boinc-client should be running BOINC applications. Additional info: My global_prefs.xml file is attached.
I feel your pain, Leonardo. I am on Ubuntu Linux (v13.10, 64-bit, Unity Desktop Environment) myself and I have the exact same issue... So, this may not be a specific distro issue. I started to notice this issue about a week ago, so I don't know if it's a BOINC software issue or if it's with the project servers that I am contributing/downloading from (which is the World Community Grid). Furthermore, I do not use BAM to manage my account, as I just have an account with WCG; so I don't think it's a BAM issue either. I am running BOINC software version 7.2.7 (64-bit), but the odd thing is I have been using this same version for months with no problems. For clarity, I have my BOINC settings to only compute when I am not using the computer for 15 minutes and I have tried changing the "While processor usage is less than" setting from 20, to 80, to now 0 (no restriction) and there seems to be no activity in my BOINC's Event Log. It's been stuck at trying to download the task files for about a week, and I leave my computer running at night so my BOINC client will conduct lots of number crunching (but obviously this isn't working right now). I typically set my max download/upload rates to 100 KBps, which should be sufficient for even large files, but there has been no attempt whatsoever for BOINC to even try downloading (according to my BOINC Event Log and my "Transfers" tab). So, just right now, I have allowed full usage (no 100 KBps restriction) of my bandwidth and have also allowed my BOINC client to use my network connection at any time (even when I am using my computer). This finally allowed all of the task files to download. I'll wait and see if my BOINC will do any work after 15 minutes of me not using the computer, as I'm trying to test whether it is a bug with the BOINC network settings. Let me know if you figure anything out. Thanks, --William
On BOINC forums they say a fix for this problem was applied starting from boinc 7.0.29 (http://boinc.berkeley.edu/dev/forum_thread.php?id=7758). I think GNOME guys have changed something on how GNOME signals mouse/keyboard activity and now Boinc can't read that information. As I don't use GNOME and cannot test, the best thing you can do is to open a bug on Boinc bug tracker (http://boinc.berkeley.edu/trac/) or at least ask for help directly on Boinc forums (maybe they're already aware of the problem and can suggest some workaround). If you open a bug on Boinc bug tracker, please post here a link to that bug.
So, I have an update for everyone. I just went ahead and upgraded my BOINC client/GUI to version 7.2.33 (64-bit) from the main BOINC website (so I am bypassing my Ubuntu specific version). It now seems to be working correctly, but it is interesting that Leonardo seems to be using this same version and is having problems. If anything, he may want to uninstall/reinstall to see if that works. Also, I am not running BOINC as a daemon like my Ubuntu version used to be, as I just used the new version by running the shell install script that essentially just unzipped the files under my account. I grabbed this version via: http://boinc.berkeley.edu/dl/boinc_7.2.33_x86_64-pc-linux-gnu.sh (http://boinc.berkeley.edu/download.php)
Leonardo can you please try this (in a shell as root): - Stop boinc daemon with 'systemctl stop boinc-client.service' - Give boinc full access to X with 'xhost +SI:localuser:boinc' - Start boinc daemon 'systemctl start boinc-client.service' This way boinc user should have full access to your user X session, check if this way it works.
(In reply to William Paul Liggett from comment #3) > So, I have an update for everyone. I just went ahead and upgraded my BOINC > client/GUI to version 7.2.33 (64-bit) from the main BOINC website (so I am > bypassing my Ubuntu specific version). It now seems to be working > correctly, but it is interesting that Leonardo seems to be using this same > version and is having problems. If anything, he may want to > uninstall/reinstall to see if that works. Hi William, Good to see that I am not alone with this issue. :) I suspect the issue lies in the interaction between BOINC and GNOME 3. From what you said, it seems that Unity used to have issues as well, but they seem to be fixed with the latest version from what you wrote. As BOINC maintainers are also focused on keeping it running on Ubuntu, I think Ubunut issues would be fixed faster than issues with other distros (or, in this case, graphical management tool). Anyway, thanks for your comments.
(In reply to Mattia Verga from comment #4) > Leonardo can you please try this (in a shell as root): > - Stop boinc daemon with 'systemctl stop boinc-client.service' > - Give boinc full access to X with 'xhost +SI:localuser:boinc' > - Start boinc daemon 'systemctl start boinc-client.service' > > This way boinc user should have full access to your user X session, check if > this way it works. Hi Mattia, Thanks for your suggestions. I executed the changes but apparently they didn't work. I'll restart the computer by the end of the day today and see if BOINC runs during the evening. I'll come back with any results here tomorrow.
I have built boinc 7.2.39 backporting a patch from 7.3 branch that fixes idle time detection on linux. Please test it (it should enter testing repositories in the next hours). However, I don't think it will fix this problem... I made quick test on a virtual machine and idle time is not yet detected running the client as a daemon, but if I run it from console by my user it works. I think that the current way boinc is used on fedora (start from systemd and run under the unprivileged 'boinc' user) is no more usable. But this is a change that should be taken by the primary maintainer (Milos).
I have just upgraded to: boinc-client-7.2.39-1.gitdc95e3f.fc19.x86_64 boinc-manager-7.2.39-1.gitdc95e3f.fc19.x86_64 xfce4-session-4.10.1-1.fc19.x86_64 etc but this BOINC bug is still there for me . . Happy to do debugging . . if someone has some suggestions as to how to go about it - otherwise I will have to start boinc-client when I remember to and when I know there is nothing the server will be doing for a while that will be impacted by BOINC running . . (my memory is not good so this will not happen often . . so the BOINC projects suffer . .). Regards, Phil.
Still happening on Fedora 21 x86_64 (Boinc v 7.2.42)
Yes, this has never been solved. Apparently no interest to run BOINC in Fedora/Gnome3. Moved this bug to Fedora 21.
To avoid any misunderstandings, in my previous comment, no interest means no one with interest/time to volunteer to the BOINC open source project and figure out what is going on. It seems we have some volunteers here to do tests, but still, need someone to volunteer and go hunt what is going on on the code.
Leonardo, OK, for the record I use XFCE not Gnome but the problem still applies. I have a little programming experience but possibly not enough to sort out the problem by myself . . is there anyone who can mentor or something? Thanks, Phil.
If it helps from what I read, the only thing that needs to happen is repackage for 7.3.x+ according to bug #1071623 they're up to 7.4.25 (which I understand may involve libraries/devel packages not deployed yet on F21). I'd be willing to help too. -e
(In reply to EMR_Fedora from comment #13) > If it helps from what I read, the only thing that needs to happen is > repackage for 7.3.x+ according to bug #1071623 they're up to 7.4.25 (which I > understand may involve libraries/devel packages not deployed yet on F21). > > I'd be willing to help too. > > -e That would be good to try. Fedora 22 is still on 7.2.42 and the issue still exists there.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is still an issue with Fedora 23.
boinc-client-7.6.22-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-268bdbd1df
boinc-client-7.6.22-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-89ece19b35
boinc-client-7.6.22-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e698a1a52
boinc-client-7.6.22-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e698a1a52
boinc-client-7.6.22-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-89ece19b35
boinc-client-7.6.22-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-268bdbd1df
The update has been unpushed due to issues with the package.
*** This bug has been marked as a duplicate of bug 1337607 ***