Since upgrading to boinc-client 7.6.22+dfsg-3 last night (when it hit
testing), I've observed it to log "No protocol specified" once a
second, except when suspended, per the log excerpt below.  As far as I
can tell, it otherwise continues to work fine, but these messages are
getting to be a nuisance.

Could you please take a look?

Thanks!

Feb  4 09:54:09 ghostwheel boinc[13404]: No protocol specified
Feb  4 09:54:10 ghostwheel boinc[13404]: No protocol specified
Feb  4 09:54:11 ghostwheel boinc[13404]: No protocol specified
Feb  4 09:54:12 ghostwheel boinc[13404]: 04-Feb-2016 09:54:12 [---] Suspending computation - computer is in use
Feb  4 10:04:17 ghostwheel boinc[13404]: No protocol specified
Feb  4 10:04:17 ghostwheel boinc[13404]: 04-Feb-2016 10:04:17 [---] Resuming computation
Feb  4 10:04:18 ghostwheel boinc[13404]: No protocol specified
Feb  4 10:04:19 ghostwheel boinc[13404]: No protocol specified
Feb  4 10:04:20 ghostwheel boinc[13404]: No protocol specified

Howdy howdy,

I suspect this is related to XOpenDisplay() calls failing during idle
detection (due to the Xserver being inaccessible for some reason). It
shouldn't be harming performance of the boinc-client in any way, but
I'll look into suppressing the log spam when the relevant calls fail.
I had already pushed all the debug log info to an optional,
non-default flag, but it looks like the XSS library might have a
hard-coded printf somewhere.

The "idle_detection_debug" log flag can be put in cc_config.xml file:

<cc_config>
  <log_flags>
    <task>1</task>
    <file_xfer>1</file_xfer>
    <sched_ops>1</sched_ops>
    <coproc_debug>1</coproc_debug>
    <idle_detection_debug>1</idle_detection_debug>
  </log_flags>
</cc_config>

See

https://github.com/BOINC/boinc/pull/1453

for the relevant pull request where I reinstated and improved the
XSS-based idle detection.

Cheers,
Preston Maness

Ugh. There's no clean way to do this that I can find, especially given
BOINC's custom handling of stdout and stderr. The closest solution
I've found that actually starts to be (thread, context, etc) safe is her
e:

https://stackoverflow.com/questions/5419356/redirect-stdout-stderr-to-a-
string

(The response from Sir Digby Chicken Caesar)

And it feels like complete overkill for what's going on. Other hacky
solutions exist --freopen() et.al.-- but I don't know if it'll step on
the toes of other parts of the boinc-client.

I can just do a poor man's timer with a decrement counter, only
retrying failing DISPLAYs every $number of minutes, which would ease
up on the amount of entries at least.

I'm going to keep mulling this over in case I can find out a better
way to handle this.

Cheers,
Preston Maness

Preston Maness <aspensmonster@riseup.net> writes:

Thanks for looking into this report, and sorry for missing your
followups.  (Copying me would have helped.)  I wound up working around
the problem for a while by holding boinc-client at the last unaffected
version, but the hard libcurl4 transition recently forced my hand,
inspiring me to take another look. ;-)

The messages did in fact turn out to be coming from X library calls
(specifically, libxcb's read_setup by way of XOpenDisplay) rather than
from BOINC itself -- that's apparently the X server's cryptic reject
message for clients it can't authenticate.  Yes, your Xsession.d hook is
in place when I'm logged in graphically, but I'm often logged in only
remotely, or logged out altogether.

I've now configured my display manager to run this hook immediately upon
launching an X server, but that's not something boinc-client can
sensibly automate: there's no universal hook directory on this front,
and at least in the case of the display manager I've been using (classic
xdm), no hook directory at all -- I had to edit a script instead.

Instead, BOINC should accommodate the possible presence of local
displays it cannot actually use.  I suppose this possibility might
interfere with the ability to assign some work to GPUs, but that
probably wouldn't be much of a loss on this particular system, which has
Intel Sandy Bridge integrated graphics. :-)

To that end, please make X_display_values_initialize (toward the end of
client/hostinfo_unix.cpp) less aggressive.  Specifically, I'd suggest
exclusively (or at least primarily) polling displays corresponding to
active utmp entries.  (At least on my system, "w" lists the display name
under FROM, which I believe corresponds to ut_host.)

Thanks!

Hi,

bug is still present in current version.

Thanks

This bug still occurs.  Could the following idea from 2016 be implemented?

One attempt per second doesn't make sense.  If we make it once every few
minutes it will significantly reduce log noise.