Hello,
I installed BOINC with yast2 but it does not connect to my boinc-client which is running, I can not setup my existing
projects?? does anyone have an idea what is wrong here.

Regards
Frik Brits

---

Please post the first 30 lines from the Event Log here, so we can have a look.

Like I said .... the manager does not connect to the client so all the menu items is grey in the manager except for the "File" and "Help" menus.

Regards
Frik Brits

Implying that the client has not started or has crashed.

No it is still running, see reply from the status command ::

frik@localhost:~> service boinc-client status

* boinc-client.service - Berkeley Open Infrastructure Network Computing Client
Loaded: loaded (/usr/lib/systemd/system/boinc-client.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2020-01-19 14:16:54 SAST; 1h 28min ago
Process: 3037 ExecStopPost=/bin/rm -f $BOINC_BOINC_DIR/lockfile (code=exited, status=0/SUCCESS)
Main PID: 3038 (boinc)
Tasks: 2
CGroup: /background.slice/boinc-client.service
`-3038 /usr/bin/boinc --dir /var/lib/boinc

Regards
Frik Brits

---

openSUSE 15.2 isn't due for release until May this year, so it's still in testing.
You may have found a bug, so it might be worth talking to "them".

No it is still running, see reply from the status command ::

If the client is actually running, wouldn't it have added the startup information to the file stdoutdae.txt in the data directory?

Have you tried browsing that file? If the startup messages aren't there, I don't think it can be running.

---

Cheers,
Gary.

Gary, I do not even have such a file anywhere and if you look back in my posts I listed the output of "service boinc-client status" that
says that the client is running.

Going back to a previous version is a problem because there are so many missing libraries that i just gave up on that too

By the way I installed this verion = 7.8.3 with the software manager : Yast2

Regards
Frik Brits

---

So I have been looking around ... there is a file called time_stats_log in the data directory here is a piece of it at the top ::

localhost:/var/lib/boinc # more daily_xfer_history.xml
<daily_xfers>
<dx>
<when>18280</when>
<up>0.000000</up>
<down>55286.000000</down>
</dx>
</daily_xfers>
localhost:/var/lib/boinc # more time_stats_log
1579386509.824124 power_on
1579386519.962329 net_unknown
1579386590.294009 proc_stop
1579386600.342053 proc_start
1579387313.121790 power_off
1579387303.450025 power_off
1579387331.614079 platform x86_64-pc-linux-gnu
1579387331.614079 version 7.8.3
1579387331.614079 power_on
1579387341.682014 net_unknown
1579388430.166830 power_off
1579388426.495450 power_off
1579436097.216203 platform x86_64-pc-linux-gnu
1579436097.216203 version 7.8.3
1579436097.216203 power_on
1579436107.353172 net_unknown
1579436213.987417 power_off
1579436208.206582 power_off
1579436218.810575 platform x86_64-pc-linux-gnu
1579436218.810575 version 7.8.3
1579436218.810575 power_on
1579436228.850576 net_unknown
1579436721.102567 proc_stop
1579436731.146546 proc_start
1579437032.446579 proc_stop
1579437042.490581 proc_start
1579438328.002559 proc_stop
1579438338.067280 proc_start
1579438448.530547 proc_stop
1579438458.574550 proc_start
1579438940.670558 proc_stop
1579438950.714550 proc_start
1579439101.382553 proc_stop
1579439111.426580 proc_start

There is entries " net_unknown" where do I fix that if it is and error, also it seems to stop and start endlessly ?
That must be and problem too?

Regards
Frik Brits

---

There is entries " net_unknown" where do I fix that if it is and error, also it seems to stop and start endlessly ?
That must be and problem too?

Running 7.16.3 here without problems and my time_stats_log also has lots of net_unknown entries so I doubt it is relevant to your problem. Sadly,I am not coming up with any ideas as to what might be causing the issue though.

Gary, I do not even have such a file anywhere and if you look back in my posts I listed the output of "service boinc-client status" that
says that the client is running.

Provided your boinc-client hasn't been modified by whoever packaged it, it will write its startup messages to the file I indicated. A previous version of that file (if it has been rotated) would be called stdoutdae.old. If you have neither of those two files, there are two possibilities that spring to mind. Either, "service boinc-client status" is lying to you and the client has never started -OR- the packager has altered the standard behaviour of the client to direct the startup messages elsewhere. For that second option, you would need to ask on the OpenSUSE forums. It's quite possible they may have done something like that.

If the client is running normally, and if the manager can't connect to it, there would have to be a reason, which would probably show up in the startup messages. If you are certain the client is running, you need to find those messages to diagnose the problem - as was asked by the very first person who responded to your question.

Can you open a terminal session and run something like 'ps -A | grep boinc' to get the process ID of the client? That would be one way of confirming that there is a running client.

---

Cheers,
Gary.

No it is still running, see reply from the status command ::

If the client is actually running, wouldn't it have added the startup information to the file stdoutdae.txt in the data directory?

Have you tried browsing that file? If the startup messages aren't there, I don't think it can be running.

Don't know if things have changed at some point but my setup is working and I don't have that file in the data directory. The only items starting with std are stderrgpudetect.txt and stdoutgpudetect.txt

There's a reference to 'boinc-client.service' in an older post. I have no experience of openSUSE, but in Ubuntu service installs the BOINC message archive is blended in with the system log (and rather overwhelms the actual system messages). If you could open your local system log viewing tool, and filter on 'boinc', you might be able to extract something useful.

Hello Dave,
Do you have a URL address where you downloaded version 7.16 ??

---

Hello Dave,
Do you have a URL address where you downloaded version 7.16 ??

7.16.3 is a testing release so may have (read, "will have") bugs though I have yet to encounter them.

https://github.com/BOINC/boinc/branches Is where I got it from but you have to roll your own. For me, that meant a lot of time chasing down dependencies. I haven't used an RPM distro since Mandrake so won't be of much help on that. My technique, each time I got a message about something being missing was if I couldn't work it out on my own to do a search on the missing dependency and then play around with version numbers if the suggested solution didn't work on Ubuntu 19.10 (It had only just come out when I compiled BOINC last so a few had changed.

Edit: However, I would be very surprised if this is just a version problem.

Have you tried starting client and manager from a terminal and looking at the output?

Re: Log files

Debian (and probably all the derivatives) have switched to using the system logs and not the text files that are used under windows, To view the logs under Debian you can use the journalctl command. You might need to prefix it with a sudo.

Example: sudo journalctl --unit=boinc-client

---

MarkJ

It just starts the gui and then it just stands there and you can not do anything because all menus are greyed except for "File" and "Help"
and of course it does not connect to my running client. Maybe I should just give up at this point.

---

In the client's log file it says "missing start tag in cc_config.xml" does this mean anything?
Also it gives this line in that same log file every second, "No protocol specified"

---

cc_config.xml is a useful, but optional, file. If it exists on your machine, it's probably there because some user created it manually - and if it's missing the start tag, then they possibly created it badly. I'd suggest you look in the BOINC data directory, and see if it's there: if it is, delete it. BOINC should run without it, and you can re-create it later if you wish. That should eliminate one variable.

It's hard to imagine what "No protocol specified" is telling us without some additional context. The only thing I know of that happens once per second is that the Manager attempts to contact the client (over TCP/IP) to obtain status updates.