"No protocol specified" message

[BryanQuigley]

I seem to get an error "No protocol specified" when I'm not logged into them machine- locked or logged off. Doesn't seem to be 100% reproducible, but most of the time. I'm using my systemd unit file from #2255.

When it occurs it logs every second. This also happens if redirected to boinc error log (but then it has no timestamps..) - the default in Ubuntu/Debian.

I've also had it actually stop boinc from running, but that could be a separate issue.

The first occurrence is sometimes followed by this dir_open fail.
Nov 22 15:57:36 desktop boinc[15002]: No protocol specified
Nov 22 15:57:36 desktop boinc[15002]: dir_open: Could not open directory '/dev/input/mice' from '/var/lib/boinc-client'.
Nov 22 15:57:37 desktop boinc[15002]: No protocol specified
Nov 22 15:57:38 desktop boinc[15002]: No protocol specified

sudo systemctl status boinc-client.service
● boinc-client.service - Berkeley Open Infrastructure Network Computing Client
Loaded: loaded (/lib/systemd/system/boinc-client.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2017-11-22 14:33:35 EST; 19h ago
Docs: man:boinc(1)
Process: 14972 ExecStopPost=/bin/rm -f /var/lib/boinc-client/lockfile (code=exited, status=0/SUCCESS)
Process: 14971 ExecStop=/usr/bin/boinccmd --quit (code=exited, status=0/SUCCESS)
Process: 14960 ExecReload=/usr/bin/boinccmd --read_cc_config (code=exited, status=0/SUCCESS)
Main PID: 15002 (boinc)
Tasks: 21 (limit: 4915)
Memory: 467.4M
CPU: 1w 5d 2h 48min 4.613s
CGroup: /system.slice/boinc-client.service
├─15002 /usr/bin/boinc
└─30949 ../../projects/sech.me_boinc_Amicable/amicable_v_2_03 /from 2^25^21715500813 /to 2^25^21715554447 /task_size 410954439845 --nthreads 16

Nov 23 10:15:04 desktop boinc[15002]: No protocol specified
Nov 23 10:15:05 desktop boinc[15002]: No protocol specified
Nov 23 10:15:06 desktop boinc[15002]: No protocol specified
Nov 23 10:15:07 desktop boinc[15002]: No protocol specified
Nov 23 10:15:08 desktop boinc[15002]: No protocol specified
Nov 23 10:15:09 desktop boinc[15002]: No protocol specified
Nov 23 10:15:10 desktop boinc[15002]: No protocol specified
Nov 23 10:15:11 desktop boinc[15002]: 23-Nov-2017 10:15:11 [---] Suspending GPU computation - computer is in use
Nov 23 10:16:40 desktop boinc[15002]: 23-Nov-2017 10:16:40 [---] Suspending computation - CPU is busy
Nov 23 10:17:40 desktop boinc[15002]: 23-Nov-2017 10:17:40 [---] Resuming computation

[BryanQuigley]

It's definitely XSS related - I built it from source and couldn't reproduce it until I installed libxss-dev and reran configure.

I think using UTMP you could have it just return not-idle when their are no users logged in.

I also tried to reduce it from checking every second but wasn't successful.

[aaronpuchert]

I'm also observing this, it's pretty annoying. The X screen saver extension is used for idle detection. On both of our machines BOINC runs under a separate user which doesn't have access to the X server. I guess that's why we are getting the message: it doesn't seem to come from BOINC, but from the code connecting to X.

Now I'm not using any option relying on idle detection (partly because it doesn't work), so why is this still queried? I guess there are four possible solutions:

1. Don't compile with XSS. Doesn't work for people using the distribution-provided packages though.
2. If settings like "only use GPU if idle" are turned off, also turn off idle detection. Meaning: only do idle detection if necessary.
3. Detect if we have the appropriate environment variables set, and if we don't, then don't even attempt calling XOpenDisplay.
4. If XOpenDisplay fails, don't call it again or back off.

[kaymio]

Since the last update on Arch Linux to boinc 7.10.3 I also get these messages in the journal.

Please let me know if I can provide you with logs or something else.

[BryanQuigley]

My current theory of how to fix this:
Use utmp to basically pull, the second field from 'who':
bryan :0 :0 22:52 ?xdm? 4:32m 0.01s

Then use that instead of /tmp/.X11/* to find non-GDM sessions.

The big cause in my tests was GDM sessions, but they aren't consistent (even though both are Ubuntu 18.04).:

1. Nvidia driver, real install
   ls -al /tmp/.X11-unix/
   srwxrwxrwx 1 root root 0 Aug 30 20:14 X0
   srwxrwxrwx 1 root root 0 Aug 30 20:14 X1

bryan :1 2018-08-30 20:14 (:1)

2. VM install
   ls -al /tmp/.X11-unix/
   srwxrwxrwx 1 bryan bryan 0 Aug 30 22:52 X0
   srwxrwxr-x 1 gdm gdm 0 Aug 30 22:49 X1024 (this is actually gdm's wayland?)

who
bryan :0 2018-08-30 22:52 (:0)

The other option is to try to use systemd's loginctl. Of course, then might as well re-implement it to just use systemd reported idle. Also afaict, this tries every option available for idle detection - maybe a bigger picture fix is needed... going to try to find a smaller fix to better learn how it works.

If anyone has this issue and different results for who or in X11-unix please let me know. Thanks!

[JuhaSointusalo]

There is a few XSS idle detection related tickets open. #2199, #2256 (this one) and #2265. I think there was one or two more but quick search didn't find them.

What is common with all of them is that were are trying to talk to the X server outside of X session and Xlib (or whatever it is that we use) isn't built for that. There's outputting unsolicited error messages, blocking waits and terminating process on errors that are not fatal to us.

I think the real fix for all of them is to move XSS idle detection to a separate process that is run inside X session for every logged in user, started in session startup script. The blocking wait and process termination are very hard to solve otherwise without using some really crazy hacks.

[nethershaw]

I have noticed that this message gets printed once a second even if I have specifically allowed my BOINC client to use the CPU and GPU while the computer is in use. The log messages still appear at the end of the value of the idle_time_to_run setting (Computing allowed / Only after computer has been idle for ... minutes) in my global preferences; if I change that setting to 0, the messages appear immediately after reloading global_prefs_override.xml.

For now it seems to be sufficient to set that value to a (very) large number to avoid the check entirely, but the client definitely should not be sensitive to this value at all if I have configured it to compute continuously. That might well be a separate issue.