Possible xhost error in boinc-client script
Gianfranco Costamagna
costamagnagianfranco at yahoo.it
Wed Dec 23 10:20:23 UTC 2015
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:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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-----
iQIcBAEBCgAGBQJWejSoAAoJEFpzcfOOuHp0Ea8P/jGyy2YhfCi8R4J85YAuLqmJ
QG9OhvtZjnsC9YazORq5DE1eWq5KnP1Yz66Fc8K9qlj2w4x6kY6WCcqZp8CxkhVs
zaj6lEMRvBP1Yr+nZkJiOI5KzWqS1518hQQZDmiY4rLnKFsGZStvzAZg98p1JAFV
VfbfVPMDLi9p/DF9lT/IWm3oqZdL6BHj5zH1kpObV2r9ZOplLic3Dt2BldOBVyoO
49xB0yq1V7iaoQThU9Z3y/Sd6Lyc7JIVnkn7u+eaIPJXb9kCjR0IFKbF54k3sUOW
AednYz2GjSf1BnGONfKy5EKnjPMMD3c9mKwdFOll2wnmpoEbU9+XWNQQqh1m2LmO
cQAcJLE80M3dw1HdWQgG2J1COG1LXSHIuaMeYP5o+mzrHyz+4Bd5dRYWx8hohiEg
xQYud2xIQUXNEKDGDYsvCSvX/vxrx+ENRRtwR2KJrx0uywAzuClD5LfimPMKm+J/
lg+H19TIzHSZMVrVBDU9zoIoeq9PP2nRO2r68DqAWprc1W2WbFE8lEenQkIUKoZW
fsf1+42rng+dquBjXq5omJxQ6ljo2mUnHv/DeWJWFVGV1M9RHXqkv3HYwwsX72q2
m5qfx8x+pa3l5WbIMT7RUlH5Q9w6Cksn83/1hUf0U822tbra8Un/PnFGwAkLLAZf
2bB3kKdNhKkPjv9PvMln
=wIz4
-----END PGP SIGNATURE-----
--
pkg-boinc-devel mailing list
pkg-boinc-devel at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
More information about the pkg-boinc-devel
mailing list