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