Possible xhost error in boinc-client script

Preston Maness aspensmonster at riseup.net
Sun Jan 3 05:38:17 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Howdy howdy,

Whelp, my pull request reinstating and improving the XSS idle
detection was accepted and merged upstream a few days ago:

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

I don't know which point release it'll end up in, but the code is
there now, along with a debug flag I added to the code for inclusion
in the cc_config.xml file named "idle_detection_debug". An example
configuration file:

"""

$ cat /var/lib/boinc-client/cc_config.xml
<!--
This is a minimal configuration file cc_config.xml of the BOINC core
client.
For a complete list of all available options and logging flags and their
meaning see: https://boinc.berkeley.edu/wiki/client_configuration
- -->
<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>

"""

The merged PR will output copious and verbose detail on XSS-based idle
detection if the idle_detection_debug flag is on (set to "1" in the
XML file). I'd edit the wiki mentioned at boinc.berkeley.edu/wiki/ to
better document this flag, but it looks like editing is disabled. May
the google-fu with the users in the years to come be strong as they
scrape the web for a copy of this mailing list's contents.

====================================================
====================================================
====================================================

With respect to my previous rantings:

> * Am I just completely ignorant of a simple/elegant solution that 
> permits boinc to start at boot, have permanent access to relevant
> Xorg sessions as they come and go, and get all of its access
> "first-shot" without the need for bouncing the client?

The PR link also has my eventual discovery of a simple, programmatic
way to handle running the appropriate xhost commands that addresses
all of these concerns. As usual, perusal of the documentation is the
best cure for ignorance. From "man 5 xsession":


"""

   CUSTOMIZING THE STARTUP PROCEDURE
       Of course, any of the existing files can be edited in place.

       Because the order in which the various scripts in
/etc/X11/Xsession.d are executed is important, files to be added to
this directory should have a well-formed name.  The following format
is recommended:

[etc etc etc]

"""

Basically, we should be able to just drop a script in
/etc/X11/Xsession.d/ that runs the appropriate xhost command. This is
already done for adding the owner of the Xserver to the ACLs:

"""

$ cat /etc/X11/Xsession.d/35x11-common_xhost-local
# This file is sourced by Xsession(5), not executed.

# 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
  xhost +si:localuser:$(id -un) || :
fi

"""

Permitting the boinc user for all Xservers as they come and go should
be as simple as adding a similar file for the boinc user:

"""

$ cat /etc/X11/Xsession.d/36x11-common_xhost-boinc
# This file is sourced by Xsession(5), not executed.

# If xhost (from x11-xserver-utils) is installed, use it to give access
# to the X server to the boinc user on the local host so that idle
# detection is functional.

if type xhost >/dev/null 2>&1; then
xhost +si:localuser:boinc || :
fi

"""

This works for me. Logging in as other users --and logging out/back in
as my normal user-- shows the boinc user in the acl list when just
running "xhost".

(Fedora and other distributions seem to have a similar setup in
/etc/X11/xinitrc/xinitrc.d/.)

This gives boinc access to DISPLAYs as they come and go. My PR just
polls the displays found in /tmp/.X11-unix/ periodically, so there's
no need for bouncing the boinc client. And finally, since it polls
periodically, boot order (for idle detection at least, can't speak for
other issues) isn't a problem.

Yay!

Cheers,
Preston Maness

On 12/23/2015 04:20 AM, Gianfranco Costamagna wrote:
> Hi folks!
> 
> thanks to you both!
> 
> I actually uploaded the fix from Preston, and I'll continue
> monitoring for progresses.
> 
> Unfortunately I never fully understood the problem in gpu
> computing, but seems that your explanation makes sense, and I hope
> you will come to a common end that will work for end users.
> 
> I don't have time/knowledge to dig into the issue, but I'm happy to
> test/upload every patch you can provide me :)
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Mercoledì 23 Dicembre 2015 6:44, Preston Maness
> <aspensmonster at riseup.net> ha scritto: Howdy howdy,
> 
> I'm in the thick of wrapping my head around BOINC's interactions
> with the X server as well, in order to get X-based idle detection
> working again:
> 
> https://github.com/BOINC/boinc/pull/1453
> 
> I've run into the same issue with making sure that boinc can access
> X server sessions to get idle information from the XScreenSaver
> API. Seeing as boinc is run as the "boinc" user, boinc doesn't
> necessarily have access to the X server sessions on boot. What
> follows might not be entirely accurate, but it's my understanding
> as of now.
> 
> Sidenote: I'm using "X server session" and "Xorg session" 
> interchangeably here. I'm still not 100 percent on what the 
> appropriate nomenclature is.
> 
> -------------------------------------------------------
> 
> At least on my own Debian Testing install, systemd is the init
> system now, and so far as I can tell the script at
> /etc/init.d/boinc-client isn't utilized. Instead, a .service file
> is used:
> 
> """
> 
> root at lolhostname:~# systemctl status boinc-client | grep Loaded 
> Loaded: loaded (/lib/systemd/system/boinc-client.service;
> disabled; vendor preset: enabled) root at lolhostname:~# cat
> /lib/systemd/system/boinc-client.service [Unit] 
> Description=Berkeley Open Infrastructure Network Computing Client 
> After=network.target
> 
> [Service] Nice=10 User=boinc PermissionsStartOnly=yes 
> ExecStartPre=/bin/sleep 1 ExecStartPre=/usr/bin/touch
> /var/log/boinc.log /var/log/boincerr.log ExecStartPre=/bin/chown
> boinc:boinc /var/log/boinc.log /var/log/boincerr.log 
> ExecStart=/usr/bin/boinc --dir /var/lib/boinc-client 
> ExecReload=/usr/bin/boinccmd --read_cc_config ExecStopPost=/bin/rm
> -f /var/lib/boinc-client/lockfile
> 
> [Install] WantedBy=multi-user.target root at lolhostname:~#
> 
> """
> 
> In any case, the init scripts would be run as the root user,
> rather than the user that owns the Xorg session that boinc is 
> utilizing/connecting to for whatever reason (idle detection, GPU 
> usage). The xhost command needs to be run by the owner of the Xorg 
> session you're trying to connect to, by design; the whole idea of
> the Xorg session ACLs is to keep external things like boinc out
> unless otherwise permitted. The init script could of course "su -"
> to the appropriate user and run the commands as necessary with the
> relevant data, though "relevant data" is tricky, seeing as there's
> no systematic way to tell which users to log in as (see below for
> more of my musings on how to tackle this. Spoiler alert: I haven't
> found a silver bullet yet).
> 
> -------------------------------------------------------
> 
> Now the tricky part is figuring out a way to:
> 
> 1.) Find all Xorg sessions, their DISPLAY values, and the owning
> user, so that we can somehow... 2.) Make sure those sessions permit
> access from BOINC if necessary... 3.) All without needing to bounce
> the "boinc-client" binary to get access to these sessions as they
> are coming and going in a multi-seat environment.
> 
> Historically, there have been issues with boinc starting before X
> and needing a restart. Presumably this is because, prior to GPGPU 
> computing, boinc only ever needed to get at the CPUs (and a network
> to get/send work units), and finagling with the X server wasn't
> really needed. But then OpenCL and CUDA happened, and now GPGPU
> computing is ubiquitous.
> 
> Unfortunately, just utilizing dependency-based init systems
> --systemd, openrc, whatever else-- isn't enough so far as I can
> tell. Or rather, it would only work for a trivial edge case in
> which there is only ever one X-server and one user login --and
> those details are further codified in the init system's state
> directly (systemd service files, etc). Any multi-user distribution,
> like Debian, wouldn't work this way (even if the typical use-case
> for a "multi-user" environment is really just one logged in user on
> a machine).
> 
> I.e., boinc can be instructed to start after "the X server" --or 
> whatever is starting an Xorg session (like GNOME)-- assuming that
> we just mean the initial Xorg session used by the login daemon for
> user switching. But this still doesn't necessarily provide access
> to the Xorg session that the GPU drivers are speaking to (or in my
> case, the Xorg session we should be monitoring for idleness).
> 
> And to top it off, this really highlights two separate use-cases
> for BOINC:
> 
> * purely CPU-based. No strict need to access Xorg session for 
> GPGPU-related work. Think of clients that only ever run something
> like Rosetta. Having access to Xorg session might be nice for idle 
> detection, but isn't strictly required for boinc itself to work.
> 
> * also running GPGPU projects. Need access to Xorg session in order
> to function (GPU detection/crunching).
> 
> These use-cases involve mutually exclusive decisions about init 
> dependencies, so I believe that relying solely on init dependency
> for proper behaviour isn't feasible. Though I'd be happy to hear
> of something I missed that addresses these problems, of course.
> 
> -------------------------------------------------------
> 
> Getting into the appropriate Xorg sessions should be feasible, at 
> least in principle. It involves scraping appropriate sources (like
> the "w" command, and probably other, cleaner APIs) for logins that
> give us usernames and DISPLAY values, and then running "su - $user
> -c 'DISPLAY=$something xhost +SI:localuser:boinc". But of course,
> what if different users log in throughout the course of the
> machine's uptime? They'll have their own Xorg sessions that the
> on-boot detection wasn't aware of. If they log in or other users
> log out, does GPU crunching still work? I don't know if GPU drivers
> are dependent/somehow linked to the "active" Xorg session.
> 
> * Should we force all users to have special on-login activities a
> la modifications to /etc/profile? What if those users don't want to
> give boinc access to their Xorg sessions? And besides, should such 
> system-wide changes be made on account of one package needing
> them? Or, is this acceptable? If a user --or, more accurately,
> system operator/administrator-- has decided to run BOINC on their
> machines, then wouldn't it be given that all logged-in users are
> providing access to BOINC so that it can crunch work units?
> 
> * Should boinc run on a per-user basis? This would eliminate our
> Xorg session woes, but still has problems with getting boinc to
> run automatically from a package management standpoint. Users might
> have lots of different DEs/WMs; how do we get them all to
> auto-start boinc appropriately? This problem is presumably why
> we're running boinc as a system service to begin with, along with
> at least rudimentary access/privilege separation.
> 
> * Is expecting boinc to restart really a deal breaker? Is there a
> way to have the client initiate the appropriate xhost actions on
> its own behalf? Or at least to periodically check that access to
> the Xorg session is available? Surely the client can just poll
> periodically, but that's not particularly elegant. Having the
> client automatically get the access it needs is desirable, but the
> whole point of ACLs from the perspective of the Xorg session is
> that outsiders --like boinc-client running under the non-login
> "boinc" user-- can't just access the Xorg sessions of other users.
> 
> -------------------------------------------------------
> 
> Finally, I suppose:
> 
> * Am I just completely ignorant of a simple/elegant solution that 
> permits boinc to start at boot, have permanent access to relevant
> Xorg sessions as they come and go, and get all of its access
> "first-shot" without the need for bouncing the client?
> 
> This email is already really long as it is, and is mostly just my
> own ramblings on this problem at this point. I'm still trying to
> figure out the entire architecture of the problem and come up with
> a solution that makes the most sense from both a boinc-client
> development standpoint and a package management standpoint. At
> present, I'm leaning toward something like adding appropriate
> commands to /etc/profile (or /etc/profile.d/$some-extra-file). The
> boinc client could then be appropriately coded to interact with
> Xorg sessions, knowing that access to them should be a given.
> 
> Perhaps others on the list can also chime in with their two cents.
> 
> Cheers, Preston
> 
> On 12/22/2015 04:53 PM, AgentB wrote:
>> Hi devs
> 
>> First a quick thank you to the Debian package maintainers, i
>> could not use BOINC without the install and run scripts.
> 
>> Apologies for the longish email.  I could not find a forum to
>> post in.
> 
>> We have been discussing a couple of startup issues relating to
>> GPU recognition over at
> 
>> http://boinc.berkeley.edu/dev/forum_thread.php?id=10641
> 
>> There are a couple of problems running OpenCL boinc tasks on 
>> startup on AMD GPUs
> 
>> I have struggled to get the boinc-client to start in init.d
>> (ubuntu 14.04) starts boinc (easy) and then (the difficult part)
>> starting OpenCL tasks
> 
>> The awkward issue seems the xhost to be set correctly.
> 
>> There is discussion of this issue, here in the past - 
>> https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/1407452
> 
> 
> 
>> In the boinc-client startup script around line 109 we see
> 
>> if [ -n "$DISPLAY" -a -x /usr/bin/xhost ]; then # grant the
>> boinc client to perform GPU computing xhost local:boinc || echo
>> -n "xhost error ignored, GPU computing may not be possible"
> 
> 
> 
>> a) xhost parameter is wrong - it probably should be
> 
>> *xhost +SI:localuser:$BOINC_USER*
> 
>> or less preferred
> 
>> *xhost +local:*
> 
> 
> 
>> b) In order for init.d startup, xhost will certainly need
>> DISPLAY to be set otherwise xhost will not be run - an error will
>> occur.
> 
>> Some examples.... in this case i have ssh'd to muon
> 
>> agentb at muon:~$ export | grep DISPLAY agentb at muon:~$ xhost #no
>> DISPLAY in environment - xhost errors xhost:  unable to open 
>> display ""
> 
>> agentb at muon:~$ export DISPLAY=":0"          #add DISPLAY 
>> agentb at muon:~$ xhost access control enabled, only authorized 
>> clients can connect SI:localuser:agentb SI:localuser:gdm 
>> SI:localuser:root
> 
>> agentb at muon:~$ xhost local:boinc                # line 109 
>> non-network local connections being added to access control list
>>  agentb at muon:~$ xhost                                  # note no 
>> boinc added but LOCAL added. access control enabled, only 
>> authorized clients can connect LOCAL: SI:localuser:agentb 
>> SI:localuser:gdm SI:localuser:root
> 
>> agentb at muon:~$ xhost -local:                     #remove LOCAL 
>> non-network local connections being removed from access control 
>> list
> 
>> agentb at muon:~$ xhost access control enabled, only authorized 
>> clients can connect SI:localuser:agentb SI:localuser:gdm 
>> SI:localuser:root
> 
>> agentb at muon:~$ xhost +SI:localuser:boinc localuser:boinc being 
>> added to access control list
> 
>> agentb at muon:~$ xhost                              #shows boinc 
>> added. access control enabled, only authorized clients can
>> connect SI:localuser:boinc SI:localuser:agentb SI:localuser:gdm 
>> SI:localuser:root
> 
> 
> 
>> c) Minor -  I'm not entirely sure that "echo -n" should be used -
>>  better a  "log_warning_msg" ?
> 
> 
> 
>> Sadly I have not quite solved the problem.
> 
>> I have tried changed the above lines my /etc/init.d/boinc-client 
>> startup to
> 
>> if [ -n "$DISPLAY" ];  then export DISPLAY=":0" fi if [ -x 
>> /usr/bin/xhost ]; then # grant the boinc client to perform GPU 
>> computing xhost +SI:localuser:boinc || log_warning_msg  "xhost 
>> error ignored, GPU computing may not be possible" fi
> 
>> but even so xhost seems to be unwilling to add boinc.
> 
>> I have also tried adding SI:localuser:boinc to /etc/X0.hosts - i 
>> don't think "localuser" is supported in X0.hosts
> 
> 
>> However, I have a Ubuntu lightdm workaround, where i modify the 
>> */etc/lightdm/lightdm.conf* file to add
> 
>> *[SeatDefaults] display-setup-script=/usr/bin/xhost 
>> +SI:localuser:boinc*
> 
>> This does work, but it's a hack.
> 
>> Hope this helps, or if you can give me some ideas to test i'll
>> be happy to do so.
> 
> 
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWiLO5AAoJEFpzcfOOuHp0SSQP/1ZLogQLiWJEREnOteZBAsx8
6d4CUc8d0fCn7+rXihLVHVDqtfeEN4h38zwhdMgw6MlMV6GkDJrtvmkWBL/6y2lS
h/6E2AdOwRtwlkrLKOFvp5+kzf6PrLZ8bZ/0WPwU7KPSkDj/dF2lDcoHhCQC2S3x
qJ9SjBlDZu75DWhHYcnOm/eanSYoDHToi3gqMniw3Qx9ZkZS/A0H+03LtBvpvz6F
Brur8Rw5frt1o+nn/Goo3nOBZI9qzOGgNI08GiKGewREt1SRB4vToMFyBLBQgiZI
XwcsO119/yFM/jb420Q8Wg1at/vQ7KvaxEC2HLKliqQlXhggVJtMaLSFD4yBR+kp
4g+UWbNTc4YRARqHfd7TjO2XWPytDfTO1oY+4UGg1Z4G66x7yP0CnAUlnyD/JR3h
EkXtOmY2BF3FNz5CU3F0fjXCojGgm63yswuu2k2SAZRHhCM9Cyan1PC7XuQk5Idm
dceNZrQ+ER266GJtj5Bfr6W99qhn8AriENp0oBdAJyWRxo7jeqtyb3TtTxqjqivB
+XxgDibrwE7IR2OdgkEqUk3XH4gHFP1wn4t64H4QY3Zn5JVHq/bOU0AXZnQlD/ZS
9AZAm3sJ5BWlqMsVhDjQqDivI6Pymum/Eo8zSgFoPCkrDUYjL98UP9peS+YUWffY
MUqAyVgC3kK0sPnpfAI9
=DVaT
-----END PGP SIGNATURE-----



More information about the pkg-boinc-devel mailing list