Anything else you come up with that could show where things go wrong, just let me know and I'll forward it to behind the scenes.

---

Anything else you come up with that could show where things go wrong, just let me know and I'll forward it to behind the scenes.

The init.d scripts which start boinc (boinc-client) do not appear to log their output, this would be helpful.

#! /bin/sh
### BEGIN INIT INFO
# Provides:          boinc boinc-client
# Required-Start:    $all
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      x11-common network-manager gdm kdm dbus lightdm
# Should-Stop:       x11-common
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: BOINC core client
# Description:       core client for the BOINC distributed computing
#                    infrastructure
### END INIT INFO

# Debian init.d script for the BOINC core client
# Copyright © 2005, 2006, 2007, 2008
# Debian BOINC Maintainers <[email protected]>

Do they visit this forum?

<snip>
In particular this

       # grant the boinc client to perform GPU computing
       xhost local:boinc || echo -n "xhost error ignored, GPU computing may not be possible"
<snip>

does not look right.

According to xhost

local contains only one name, the empty string

I would suggest this should be xhost +SI:localuser:$BOINC_USER

Even if corrected - i suspect this xhost line may produce an error, and it needs to be seen.

Do they visit this forum?

Depends on who you mean with 'they'. :)

If in this case the

# Debian init.d script for the BOINC core client
# Copyright © 2005, 2006, 2007, 2008
# Debian BOINC Maintainers <[email protected]>

I doubt it.

And it's been a while since I ran the Berkeley BOINC installer on a Linux-derivate, but does the Berkeley installer use init.d? I think those are only used by the BOINC maintained by package maintainers, started as a daemon.

So, in this case you'll have to find the package maintainer for Debian and tell him or her that. Sorry, I know it sounds very easy to point to others, but there is really no sense in asking the developers about something they didn't add to the package in the first place.

By default the Berkeley installer unpacks everything in the home folder, and you start the client and manager by hand.

Edit.. I think Gianfranco Costamagna is also the Debian maintainer these days.

---

client (Unix): if libOpenCL.so isn't there, try libOpenCL.so.1

That what you wanted, Juha?

YEEEEESSSSSSSSSSSSS!!!!!!!

client (Unix): use dlerror() for GPU library failures; shows the filename

05-Dec-2015 23:55:22 [---] [coproc] launching child process at ./boinc
05-Dec-2015 23:55:22 [---] [coproc] relative to directory /tmp/b/BOINC
05-Dec-2015 23:55:22 [---] [coproc] with data directory /tmp/b/BOINC
05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms
05-Dec-2015 23:55:22 [---] No usable GPUs found

Thanks. You are a hero!

Glad you like it. On the hero stuff though, all I did was gather some of your comments from three different threads and send those off to the developers, pointing out the validity of those points. After which they nodded, agreed and added the new code. So you're as much a hero as anyone else. :)

I then saw Agentb post his post and thought, yep let's forward that part of dlerror(), and although I asked for it to be part of coproc_debug, David made it show always. Probably just as well.

Now, if only I knew what the errors meant and how to solve them. ;-)

---

Now, if only I knew what the errors meant and how to solve them. ;-)

I tried (and failed) to find a list of dlerrors, but seeing them is half way to solving them. I'm sure the dlopen of "libOpenCL.so.1" will make for more working GPUs by default (and less errors!) - that will help - a lot.

Regarding the install scripts, i'll have a look at the Berkeley installer tomorrow... but if the package installers are introducing problems we should not turn a blind eye to it, especially when we promote their use in the boinc documentation. There are a number of very good healthy reasons to run as user=boinc, and this functionality should be part of BOINC imho.

05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms

Those messages need not, and should not, be part of the standard startup output. That information is usually not needed and is likely to cause confusion because it will be misinterpreted as errors. Instead make it debug output and perhaps add a hint to the list of detected GPUs to turn on debugging if the list is not correct.

05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms

Those messages need not, and should not, be part of the standard startup output. That information is usually not needed and is likely to cause confusion because it will be misinterpreted as errors. Instead make it debug output and perhaps add a hint to the list of detected GPUs to turn on debugging if the list is not correct.

Good point, I guess you mean we needed a summary log entry for each component saying "ok / not ok" and then another log entry to say "for more detail set the coprocessor debug flag"?

Would it be better leaving them in but make more user friendly (to the few people looking at it). We are logging now the linked library versions and details of other required components such as CPU capabilities at start.

Perhaps start with

"GPU and driver search phase - expect 'Not found' if no GPU installed" 

And instead of just

NVIDIA: libcuda.so.1: cannot open shared object file: No such file or directory

use a clearer

NVIDIA: CUDA library: Not found : (libcuda.so.1: cannot open shared object file: No such file or directory)

and (in a perfect world) if dlopen returns no error

NVIDIA: CUDA library: Found. (libcuda.so.1)

I would expect a debug flag if set for example to to show dladdr() information - which reports the full library path etc. That would help with symbolic and version issues (different .so and .so.1 for example)

If all this detail is deemed too much (three or four lines) then we need to put a very good hint about how to set the debug flags.

I agree, and I asked originally they be put under the coproc_debug flag, will re-ask that once more.

---

I guess you mean we needed a summary log entry for each component saying "ok / not ok" and then another log entry to say "for more detail set the coprocessor debug flag"?

Not exactly, I'd basically keep it the way it is. Just list the detected GPUs and don't mention any others unless specificially asked, i.e. coproc_debug. We don't want to confront the user with everything that could be a problem, they just need to know what to do if there really is one. And there I can't think of anything better than a message in this place, though it doesn't really belong here in my opinion. Nobody seems to think of debug mode even if they know there's something wrong.

We are logging now the linked library versions and details of other required components such as CPU capabilities at start.

We are logging what we know about the system, not how we found out or what we don't know. I think we should stick with that scheme.

NVIDIA: CUDA library: Found. (libcuda.so.1)

If we find a GPU the user doesn't need to know how we did it. If we don't find a specific type we should only mention it if we know that something went wrong. But we can't know, only the user can.

So, in this case you'll have to find the package maintainer for Debian and tell him or her that. Sorry, I know it sounds very easy to point to others, but there is really no sense in asking the developers about something they didn't add to the package in the first place.

By default the Berkeley installer unpacks everything in the home folder, and you start the client and manager by hand.

Edit.. I think Gianfranco Costamagna is also the Debian maintainer these days.

BOINC Wiki says BOINC: compute for science Page "if available, we recommend that you install a distribution-specific package instead."

I think BOINC - Debian wiki is close to answers and especially associated git

It would be helpful to have a paragraph at the end of each http://boinc.berkeley.edu/wiki/Installing_BOINC_on_<distro> labelled Package Maintainer with the Debian or similar URL.

I'll drop them a line about xhosts

I looked at the installer provided as the Berkeley. It did not provide any daemon or start-up functionality, other than change directory and start the boinc executable.

Guys, even though the messages were lacking the [coproc] prefix they were debug log messages.


I'll do a bit more research on the xhost stuff later. I think it's going to be a bit harder nut to crack.

https://github.com/BOINC/boinc/commit/38ae01d1fded626162eaa0b5c3685cf720e0fd49

client: prepend [coproc] to coproc_debug msgs

---