Linux Suspend when computer is in use bug.

Message boards : Questions and problems : Linux Suspend when computer is in use bug.
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Marc Chamberlin
Avatar

Send message
Joined: 24 Nov 09
Posts: 14
United States
Message 101130 - Posted: 17 Oct 2020, 19:08:28 UTC

I am running BOINC Manager Version 7.16.6 (x64) with wxWidgets Version 3.0.3 on several OpenSuSE 15.2 linux systems and I am wondering when, if ever, the bug for detecting when the computer is in use will be fixed. This bug has been around for about 13 years now (see Ticket #463) and I posted a query about this bug back in 2011. My workaround has been to manually suspend BOINC when I want to work on the computer (BOINC can seriously degrade performance at times) but the problem is that I forget to restart BOINC after working for several hours on other tasks.

If there is a serious reason why this bug can't get fixed, perhaps a good interim solution would be to present an additional option to suspend BOINC for a user specified length of time, and then automatically restart it when the specified time expires.

Incidentally FYI The link under the Help menu to report an issue is broken sometimes. Sometimes it points the the BOINC site and sometimes it points to some unrelated website. DNS issue?
Marc Chamberlin
Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new hardware. To seek out new software and new applications.
To boldly go where no Marc has gone before!
ID: 101130 · Report as offensive
Les Bayliss
Help desk expert

Send message
Joined: 25 Nov 05
Posts: 1486
Australia
Message 101135 - Posted: 18 Oct 2020, 4:42:49 UTC - in response to Message 101130.  

BOINC 7.6.31 works fine in Mint.
ID: 101135 · Report as offensive
Profile Dave

Send message
Joined: 28 Jun 10
Posts: 1377
United Kingdom
Message 101137 - Posted: 18 Oct 2020, 6:52:41 UTC - in response to Message 101135.  

BOINC 7.6.31 works fine in Mint.


Interesting, I checked this function or lack of it yesterday with 7.17.0 that I compiled from source and suspend when computer is in use is certainly not happening with Ubuntu20.04. Ticked and saved, the tasks running were all using 100% of their core.

Suspend when non-boinc usage is above n% on the other hand seems to work fine though since I started using my new Ryzen, I have to set n very low in order to demonstrate this.
ID: 101137 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 75
Message 101138 - Posted: 18 Oct 2020, 11:11:01 UTC

Debian's BOINC does "xhost +si:localuser:boinc", I suspect that's required for idle detection. Can't tell for sure, I have disabled it.
Remember there's the idle_detection_debug log flag.
ID: 101138 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101139 - Posted: 18 Oct 2020, 11:27:52 UTC

In https://github.com/BOINC/boinc/issues/3715, I've recently posted the output of the 'idle_detection_debug' log under Mint.

Sun 11 Oct 2020 15:43:28 BST | | [idle_detection] Error (2) opening /tmp/.X11-unix/.
Sun 11 Oct 2020 15:43:28 BST | | [idle_detection] Could not connect to any DISPLAYs. XSS idle determination impossible.
and noted

There is a 'socket file' called X0 in /tmp/.X11-unix/
I'll try that xhost command later, and report back.
ID: 101139 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14626
Netherlands
Message 101141 - Posted: 18 Oct 2020, 12:35:26 UTC - in response to Message 101130.  

If there is a serious reason why this bug can't get fixed
Simply said, it really depends on the distribution you use whether it works or not, and there's no guarantee that will stay working for future iterations of that distro. For some X11/XScreensaver is used for idle detection, for others systemd and when the developer of the distro makes a change in either, that will break BOINC's idle detection. Or even make it possible to use on distros that for long couldn't use it.

A user definable timer could work. But you'll have to ask for that on Issues (search if there's none there yet or your ticket will be closed).
Other automated workarounds comprise using the exclusive applications option (as long as a certain application is detected in memory, BOINC suspends work), or the "non-boinc usage is above n%" option.
ID: 101141 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101142 - Posted: 18 Oct 2020, 15:09:02 UTC - in response to Message 101139.  

I'll try that xhost command later, and report back.
Tried it (with sudo). Got the response

localuser:boinc being added to access control list
which looks hopeful - but still the same error message in idle_detection_debug. I'll try a reboot, as seemed necessary when adding my user account to the boinc group.
ID: 101142 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101143 - Posted: 18 Oct 2020, 15:28:14 UTC - in response to Message 101142.  

Sorry, no. Still "XSS idle determination impossible."

Next?
ID: 101143 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 75
Message 101146 - Posted: 18 Oct 2020, 17:41:21 UTC - in response to Message 101142.  

I'll try that xhost command later, and report back.
Tried it (with sudo). Got the response

localuser:boinc being added to access control list

That looks as expected.

still the same error message in idle_detection_debug. I'll try a reboot

xhost settings are not persistent. That's why Debian has this:

$ cat /etc/X11/Xsession.d/36x11-common_xhost-boinc 
#
# Some boinc headers needed so if some poor admin stumbles across this he knows where it came from...
#
# This file is sourced by Xsession(5), not executed.
BOINC_USER=boinc
#
# If xhost (from x11-xserver-utils) is installed, use it to give access
# to the X server to any process from the same user on the local host.
# Unlike other uses of xhost, this is safe since the kernel can check
# the actual owner of the calling process.

if type xhost >/dev/null 2>&1; then
  id -u $BOINC_USER >/dev/null 2>&1 && xhost +SI:localuser:$BOINC_USER || :
fi

Ignore the comments. Everything not explicitly mentioning BOINC has been copied from 35x11-common_xhost-local. I routinely comment out the last three lines, I prefer not to grant all the BOINC world access to my X server.

So after it didn't work for you I decided to try it myself for comparison. The initial setup was like this:
- BOINC 7.14.2 from Debian
- "Suspend when computer is in use" (SUSPEND) off
- idle_detection_debug (DEBUG) off
- "xhost +si:localuser:boinc" (XHOST) unset as mentioned above

I switched SUSPEND on and nothing happened. Set XHOST and computation was suspended. After a while, possibly the configured 3 minutes, computation resumed. Then I unset XHOST again. While typing, BOINC suspended but resumed soon after the command. All as expected so I switched SUSPEND off again.

Now comes the confusing part. I wanted to do all again with DEBUG on. Set DEBUG, set SUSPEND, and ... suspended. Without XHOST. Switched SUSPEND back and forth, suspension followed. Turned DEBUG off, still the same. Even after a reboot. I don't know what happened there, I can only imagine it was one of those little services that run in the background for my "convenience", without my knowledge, where only the gurus can tell what the hell they're doing exactly. Oh how I hate that. However, after a while and another reboot things returned to normal. But during all that I never saw any debug output. Maybe someone can make sense of that, I can't.
ID: 101146 · Report as offensive
Marc Chamberlin
Avatar

Send message
Joined: 24 Nov 09
Posts: 14
United States
Message 101174 - Posted: 20 Oct 2020, 16:05:53 UTC - in response to Message 101146.  

Thanks everyone for all your responses and efforts at looking into this bug. So far as I grok this thread, I understand/summarize 4 responses -

1. It works for me on Mint. (Interesting but not helpful for OpenSuSE.)
2. I got it working on Debian using a xhost command to add user boinc. ( I tried that, on a command line but no joy. I don't have the Xsession file that was referenced, on a Debian distro, not even the Xsession dir, so dunno how to to persist this on OpenSuSE.)
3. A finger pointing back at my distro saying the problem lies there. (I will post a question on their forums about this issue.)
4. Workarounds including
using the exclusive applications option (as long as a certain application is detected in memory, BOINC suspends work), or the "non-boinc usage is above n%" option.
(Helpful but not good solutions for me. Dunno what I could use for an exclusive app, I often use most applications for days at a time and simply leave them running where I left off. (I don't log off) As for non-boinc usage I am already setting it but dunno what I should set it to to differentiate between when I am using it and background apps are running (such as a backup process)

So not sure what to do next, will report back if the OpenSuSE forums provide any help. Is there any way to know how BOINC is detecting the idle state on my systems? i.e. using X11/Xscreensaver or systemD? What would be good info to supply the developers/users on their forums?

Thanks again in advance for taking the time to respond and looking forward to any more helpful suggestions. Marc...
Marc Chamberlin
Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new hardware. To seek out new software and new applications.
To boldly go where no Marc has gone before!
ID: 101174 · Report as offensive
ProDigit

Send message
Joined: 8 Nov 19
Posts: 633
United States
Message 101207 - Posted: 22 Oct 2020, 0:41:01 UTC

I don't get it,

CPU resources are dynamically allocated.

Boinc WUs have the nicest nice factor, meaning they will give any application the CPU resources it needs, leaving the remaining CPU resources for itself.

If you feel like your CPU intensive programs are not getting the CPU resources they need, set their nice factor to less nice.
Or, in Windows, set your thread priorities to higher.
ID: 101207 · Report as offensive
Profile Dave

Send message
Joined: 28 Jun 10
Posts: 1377
United Kingdom
Message 101214 - Posted: 22 Oct 2020, 13:03:46 UTC

Interestingly, while on my system use of mouse/KB doesn't suspend computing even if "suspend while computer is in use" for the CPU, it does for the GPU and my single GPU task will display an the manager as suspended if I tick, "suspend GPU computing when computer is in use."

(Ubuntu 20.04 BOINC7.17.0)
ID: 101214 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101216 - Posted: 22 Oct 2020, 13:58:56 UTC - in response to Message 101214.  
Last modified: 22 Oct 2020, 14:15:22 UTC

What are the 'idle_detection_debug' messages in that scenario? Does that GPU have a monitor attached - i.e., is it known to the xhost?

I'll try answering those questions on one of my Mint systems, too.

Edit - sadly, doesn't work here. Still

Thu 22 Oct 2020 15:11:33 BST |  | [idle_detection] Error (2) opening /tmp/.X11-unix/.
Thu 22 Oct 2020 15:11:33 BST |  | [idle_detection] Could not connect to any DISPLAYs. XSS idle determination impossible.
ID: 101216 · Report as offensive
Profile Dave

Send message
Joined: 28 Jun 10
Posts: 1377
United Kingdom
Message 101217 - Posted: 22 Oct 2020, 15:55:37 UTC - in response to Message 101216.  

All I have at the moment is

Wed 21 Oct 2020 13:10:19 BST | | Suspending GPU computation - computer is in use
Wed 21 Oct 2020 13:13:19 BST | | Resuming GPU computation


Will set debug flags and check again. Strange, copied above from event log earlier but now,

Thu 22 Oct 2020 16:53:38 BST |  | [idle_detection] Error (2) opening /tmp/.X11-unix/.
Thu 22 Oct 2020 16:53:38 BST |  | [idle_detection] Could not connect to any DISPLAYs. XSS idle determination impossible.
ID: 101217 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101218 - Posted: 22 Oct 2020, 16:20:43 UTC
Last modified: 22 Oct 2020, 16:31:34 UTC

It seems that we have to put our thinking caps on, and start reading at

https://github.com/BOINC/boinc/blob/master/client/hostinfo_unix.cpp#L1806

Observations so far:

It seems (and it's a pity) that this is is simply theoretical - just RTFM
The first error message is simply a failure to open a directory (line 1825). Errnum 2 may elucidate.
The second error message reports "none of the Xservers were queryable" (line 1948)
Apart from that, we're looking for a needle in a haystack - or an XScreenSaver running on an Xserver. Send out the search parties.

I'm getting "#define ENOENT 2 /* No such file or directory */" - but I can see it on my machine. ??
ID: 101218 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101234 - Posted: 23 Oct 2020, 14:39:25 UTC - in response to Message 101218.  

The first error message is simply a failure to open a directory (line 1825). Errnum 2 may elucidate.

I'm getting "#define ENOENT 2 /* No such file or directory */" - but I can see it on my machine. ??
So, after letting my head spin round it a bit, I thought "Can we find the list of X servers any other way - like a static list?"

Er, no - that's such a convoluted bit of code. What a stupid way of assembling a list of strings.

So then I thought, why don't we put the same list in a place where we know BOINC can read it?

I tried to copy the existing folder into boinc_client, but Mint refused - copied the folder, but not the contents. "Can't copy special file" - which seems like a bit of a clue in itself. So I made a new file - empty, two-character name, just like the old one - says it's a text file instead of a socket file, but who's counting by this stage?

Built a new client with the new location - AND IT WORKS! Now to tell git...
ID: 101234 · Report as offensive
Profile Dave

Send message
Joined: 28 Jun 10
Posts: 1377
United Kingdom
Message 101235 - Posted: 23 Oct 2020, 14:52:42 UTC

Built a new client with the new location - AND IT WORKS! Now to tell git...


Well done!

I am still from time to time getting,
Fri 23 Oct 2020 11:04:12 BST |  | don't use GPU while active
Fri 23 Oct 2020 11:04:12 BST |  | Setting up GUI RPC socket
Fri 23 Oct 2020 11:07:04 BST |  | Suspending GPU computation - computer is in use
Fri 23 Oct 2020 11:09:52 BST |  | Resuming GPU computation
from time to time but never when i have idle_detection debug enabled and the rate at which it fills up the log is a bit too fast for me to want to leave it on for longer than a quick check. So whatever does occasionally tell BOINC my computer is in use and suspends GPU computation isn't simply moving the mouse or using the keyboard.

For the record, the latest messages from the log are after upgrading to Groovy. (20.10)
ID: 101235 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 75
Message 101238 - Posted: 23 Oct 2020, 17:22:39 UTC - in response to Message 101234.  
Last modified: 23 Oct 2020, 17:50:31 UTC

So, after letting my head spin round it a bit, I thought "Can we find the list of X servers any other way - like a static list?"
Look at the comment in the file you referred to, line 1809. It says BOINC already does use a static list as a fallback:
If we can't open this
    // directory, or the display_values vector is otherwise empty, then a
    // static list of guesses for open display servers is utilized instead
    // (DISPLAY values ":{0..6}") that will attempt connections to the first
    // seven open Xservers.

But I can't find that in the code.

So I made a new file - empty, two-character name, just like the old one - says it's a text file instead of a socket file, but who's counting by this stage?

Built a new client with the new location - AND IT WORKS! Now to tell git...
Tell git what? That you want to mimic what you can't read originally in some other place, where you have to set it up yourself and can't be sure it gives the same information the original would? That's an ugly workaround, no better than what the comment suggested and more complicated. Instead of re-inventing the wheel I think you'd better find a copy of the code that was apparently removed, but understand why it was.

Edit: Found it, it's https://github.com/BOINC/boinc/commit/7ff020c48781099c02c71020e2518a0bd13c65c3, also saying why the code was removed. If that is correct your idea wouldn't work better.
It's a recent change by the way. That could explain different behaviour between clients.
ID: 101238 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4498
United Kingdom
Message 101240 - Posted: 23 Oct 2020, 18:44:30 UTC - in response to Message 101238.  

Well, mine wasn't intended to be a fix, just a 'proof of concept' to show that I had localised that 'error(2)' and suggesting that it was the last remaining blockage.

As to exactly why BOINC can't access that file (name) - I don't know. It may be somewhere in the systemd implementation: the original manual that David describes reading sounds like it ought to be world-readable, and the permissions I could read were 777.

But isn't BOINC supposed to be sandboxed under systemd. Could that block out the rest of the world?
ID: 101240 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 75
Message 101242 - Posted: 23 Oct 2020, 18:57:13 UTC - in response to Message 101218.  

I'm getting "#define ENOENT 2 /* No such file or directory */" - but I can see it on my machine. ??
I couldn't imagine how you could get ENOENT when trying to open /tmp/.X11-unix/ but now I have a theory. Maybe you want to verify it.

If you run BOINC as a systemd service and you have PrivateTmp=true configured or something to that effect, BOINC should have its own /tmp where /tmp/.X11-unix/ doesn't exist. If so you'd need to give the BOINC service access to the global /tmp. I'm not sure if that is advisable but can't think of any risks now. On the other hand, as shown above one often can think of something the next day.
ID: 101242 · Report as offensive
1 · 2 · Next

Message boards : Questions and problems : Linux Suspend when computer is in use bug.

Copyright © 2021 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.