After the latest update:
uname -a shows:
4.15.0-70-generic #79-Ubuntu SMP

And boinc-client won't start.

syslog after "sudo service boinc-client restart"
systemd[1]: boinc-client.service: Main process exited, code=exited, status=76/n/a
systemd[1]: boinc-client.service: Failed with result 'exit-code'.
That does not look good.

Some details follow:

boincmgr will start up but of course cannot find projects without
the client running.
I switch to the noveau Linux driver, remove nvidia, and reselected nvidia 435 package
on the additional drivers panel. (most recent driver available)

(with several reboots in there)
Plus sudo apt install of
nvidia-modprobe boinc-client-nvidia-cuda nvidia-opencl-dev
The GPUs are nvidia GTX 760's (two of them).

Here is more detail. I emptied gui_rpc_auth.cfg (/var/lib/boinc-client and my $HOME)

on boinc-client restart I see more detailed info now:

Nov 14 13:47:15 dseti3 boinc[3869]: 14-Nov-2019 13:47:15 [---] gui_rpc_auth.cfg is empty - no GUI RPC password protection
Nov 14 13:47:15 dseti3 boinc[3869]: 14-Nov-2019 13:47:15 [---] GUI RPC bind to port 31416 failed: 98
Nov 14 13:47:16 dseti3 boinc[3869]: 14-Nov-2019 13:47:16 gstate.init() failed
Nov 14 13:47:16 dseti3 boinc[3869]: Error Code: -180
Nov 14 13:47:16 dseti3 systemd[1]: boinc-client.service: Main process exited, code=exited, status=76/n/a

Can you run the client in the terminal on its own? At least that way you can see the startup, stdoutdae and any errors. Open a Terminal in /usr/bin and execute:

./boinc

[Edit]
You have a rpc permission problem:
https://boinc.mundayweb.com/wiki/index.php?title=Gstate.init()_failed,_error_code:_-180

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

This error happens when the user has no permission to use the RPC port number, or forgotten to allow it through the firewall.
Happens in combination with Gstate.init() failed, error code: -180

I removed the two gui_rpc_auth.cfg files which still resulted in the -180 error
on restarting boinc-client attempts

sudo ufw status
Status: inactive
So it's not a firewall issue. ?

Turned on <gui_rpc_debug>1</gui_rpc_debug>
and on restart lots of
repeats ending:
Nov 14 14:09:01 dseti3 boinc[4424]: 14-Nov-2019 14:09:01 [---] [gui_rpc] Remote control allowed
Nov 14 14:09:02 dseti3 boinc[4424]: 14-Nov-2019 14:09:02 [---] [gui_rpc] found allowed hosts list
Nov 14 14:09:02 dseti3 boinc[4424]: 14-Nov-2019 14:09:02 [---] [gui_rpc] Remote control allowed
Nov 14 14:09:03 dseti3 boinc[4424]: 14-Nov-2019 14:09:03 [---] [gui_rpc] found allowed hosts list
Nov 14 14:09:03 dseti3 boinc[4424]: 14-Nov-2019 14:09:03 [---] [gui_rpc] Remote control allowed
Nov 14 14:09:04 dseti3 boinc[4424]: 14-Nov-2019 14:09:04 [---] [gui_rpc] found allowed hosts list
Nov 14 14:09:04 dseti3 boinc[4424]: 14-Nov-2019 14:09:04 [---] [gui_rpc] Remote control allowed
Nov 14 14:09:05 dseti3 boinc[4424]: 14-Nov-2019 14:09:05 [---] [gui_rpc] found allowed hosts list
Nov 14 14:09:05 dseti3 boinc[4424]: 14-Nov-2019 14:09:05 [---] [gui_rpc] Remote control allowed
Nov 14 14:09:05 dseti3 boinc[4424]: 14-Nov-2019 14:09:05 [---] GUI RPC bind to port 31416 failed: 98
Nov 14 14:09:06 dseti3 boinc[4424]: 14-Nov-2019 14:09:06 gstate.init() failed

I had an issue with rpc when I upgraded my RPi 3B+ to Buster. Something in that upgrade "grabbed" port 31416 for its own use. Never did install the necessary tools to figure out who did that. My solution was just to move the client to port 31417 instead and that solved the problem. Annoying but I didn't want to spend any more time troubleshooting what changed.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

netstat -atup
shows

tcp 0 0 localhost:31416 localhost:46794 TIME_WAIT -

Well. boinc is active! Killing and service boinc-client restart restarts things
but nothing changes.

lsof shows:
boinc 16514 boinc 5u IPv4 137043 0t0 TCP *:31416 (LISTEN

But boinc not working.
On a working system most of this looks the same, but boinc-client shows as active with
service --status-all

boinc 16514 boinc 5u IPv4 137043 0t0 TCP *:31416 (LISTEN)
(previous post lost part of the line)
so it's boinc itself. ?

Killed and restarted boinc with --gui_rpc_port 31417 and syslog winds up after
sudo service boinc-client restart
with:
Nov 14 15:05:37 dseti3 boinc[17112]: 14-Nov-2019 15:05:37 [---] [gui_rpc] got new GUI RPC connection
14-Nov-2019 15:05:38 [---] [gui_rpc] GUI RPC Command = '<boinc_gui_rpc_request>
Nov 14 15:05:38 dseti3 boinc[17112]: <auth1/>
Nov 14 15:05:38 dseti3 boinc[17112]: </boinc_gui_rpc_request>
Nov 14 15:05:38 dseti3 boinc[17112]: '
Nov 14 15:05:38 dseti3 boinc[17112]: 14-Nov-2019 15:05:38 [---] [gui_rpc] GUI RPC reply: '<boinc_gui_rpc_reply>
Nov 14 15:05:38 dseti3 boinc[17112]: <nonce>1573772738.325697</nonce>
Nov 14 15:05:38 dseti3 boinc[17112]: </boinc_gui_rpc_reply>
Nov 14 15:05:38 dseti3 boinc[17112]: '
Nov 14 15:05:38 dseti3 boinc[17112]: 14-Nov-2019 15:05:38 [---] [gui_rpc] GUI RPC Command = '<boinc_gui_rpc_request>
Nov 14 15:05:38 dseti3 boinc[17112]: <auth2>
Nov 14 15:05:38 dseti3 boinc[17112]: <nonce_hash>b3ad3233193c7e375f0b4399efe0fc5f</nonce_hash>
Nov 14 15:05:38 dseti3 boinc[17112]: </auth2>
Nov 14 15:05:38 dseti3 boinc[17112]: </boinc_gui_rpc_request>
Nov 14 15:05:38 dseti3 boinc[17112]: '
Nov 14 15:05:38 dseti3 boinc[17112]: 14-Nov-2019 15:05:38 [---] [gui_rpc] GUI RPC reply: '<boinc_gui_rpc_reply>
Nov 14 15:05:38 dseti3 boinc[17112]: <unauthorized/>
Nov 14 15:05:38 dseti3 boinc[17112]: </boinc_gui_rpc_reply>
Nov 14 15:05:38 dseti3 boinc[17112]: '
Nov 14 15:05:38 dseti3 boinc[17112]: 14-Nov-2019 15:05:38 [---] [gui_rpc] handler returned -155, closing socket

No joy.

Maybe you can draw Jord's attention to this thread. He is the expert with gui_rpc_auth issues.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Thanks, that's a new one for me. :-)

David, you say you removed gui_rpc_auth.cfg, so that upon the next client restart it's made automatically.
When it's made, is there anything in it?
What if you remove that line and put in your own password?

bind error 98 means the user account that starts BOINC doesn't have permission to use the port number.
I'm not really well versed in Linux, but what happens if you temp run BOINC as root? Just for testing, not for prolonged use.

If root can run BOINC with any gui_rpc_auth.cfg file, it may be that the 31416 port number is reserved. You should either try to run with a different port number, or... uhm, is your user part of the boinc group?

---

Thanks for thinking about this, Jord. Your comments got
me thinking again. Thanks to Keith too.

BTW: On none of my machines am I as user part of the boinc group.

Problem solved, boinc and seti@home running.

I kept focusing on /var/lib/boinc-client/gui_rpc_auth.cfg
and its content.
But crucially /etc/boinc-client/gui_rpc_auth.cfg
needs to have the same content!
The latter owned by root, the former owned by boinc.

I was lacking /etc/boinc-client/gui_rpc_auth.cfg ! No file!
While /var/lib/boinc-client/gui_rpc_auth.cfg was present with
20 or 30 character string.

With each of them containing a single newline character
then boincmgr can rpc with boinc and my project
becomes visible and the GPUs are visible.
With a failed rpc boincmgr came up ok but showed no project(s)
and no GPUs.

The updates changed one of the files (I think) so they were
inconsistent. I deleted /etc/boinc-client/gui_rpc_auth.cfg
and then things were still inconsistent as /var/lib/boinc-client/gui_rpc_auth.cfg
kept getting recreated by sudo service boinc-client but could not match
the missing /etc/boinc-client/gui_rpc_auth.cfg
.
Now /etc/boinc-client/gui_rpc_auth.cfg and /var/lib/boinc-client/gui_rpc_auth.cfg
have identical content.

Summary: It's surely my own fault as a result of something I did in the
past which maybe conflicted a bit with standard use of these files
so the install was just doing its thing normally.

Glad to have nudged something that it got fixed. :)

---

Great troubleshooting and persistence David.

Glad you got it working. I would not have realized the gui_rpc_auth.cfg is in two places and different groups. I don't have much experience with the default BOINC installation as I run the TBar version in /home on all hosts other than the oddball ARM RPi. I did move BOINC to /home on the Nano since I was doing development on that platform and the usual group/user ownership of the default BOINC installation on the ARM64 platform was getting in the way. Never bothered with the RPi though. Wonder if the dual locations of the file is what caused my rpc issues after the Buster upgrade. Need to investigate.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)