The title pretty well covers it: I had an update along with a bunch of other stuff last night; got up this morning, and my fan seemed too quiet. Conky shows near-zero CPU. Open BOINC Manager, no projects, never mind tasks. Everything in the menus (advanced view) is grayed out, except the File and Help menus.

I presume I need to "reconnect" the manager, but there are no instructions in the manager help for doing so (that I've found), and something I need to do once or twice a year just doesn't stick.

I'm running Ubuntu Mate 16.04.5 on AMD FX8350 (8 cores, 8 threads, up to 4.1 GHz) with 16 GB RAM, nVidia GTx950, and this ran perfectly (if a little noisily due to high fan speed) before last night's update. Same thing happened with my laptop (Same Ubuntu version, Core i7-3250 Mobile, 2 cores, 4 threads, up to 3.5 GHz, 8 GB RAM, Intel graphics) after a similar update on Saturday the 28th.

If this is BOINC 7.10.1 then revert to a previous version. Due to a bug the client doesn't run, only the Manager.

Don't use BOINC 7.10.1

---

Bingo. Ubuntu had an update available this morning, still marked at 7.10.1, but now my clients (Einstein and Milkyway) started right up and picked up where they left off.

Jord does the Ubuntu 18.04 Desktop Manager Gnome have anything to do with this problem? If I create a boincmgr.desktop file so I can dock the Manager, when I invoke it, all it does is open the Manager window and doesn't start the client. I am running TBar's 7.4.44 BOINC.

If I start boincmgr from the BOINC folder, the Manager window opens up and starts the client normally.

I have posted in the gnome developers buglist and they have brushed me off and said the problem is with BOINC. TBar also has said his version works fine in every previous distribution and desktop manager.

So right now I am out of help since both parties are pointing blame at each other.

To be honest, I don't know. But I saw you asked it in Issue #2339 as well, so that's probably where the answer comes in.
My expertise is with Windows, not Linux. I leave that to others - MarkJ, Juha - to answer.

---

Hi Jord, yes I am posting all over the place trying to get some traction and answers. Update is now I can dock the Manager and it executes properly and connects to the client when launched from the Dock. I didn't do anything to the Boinc files. Also I made no changes to the Ubuntu 16.04/Unity boincmgr.desktop file that I borrowed from one of my 16.04 machines. That file enabled me to dock the Manager but the app only opened the Boinc Manager window and never connected to the client.

What changed was that I needed to add python-numpy and xdotool packages to the system to get Jeff's Seti Rescheduler running on this new system. Those two packages pulled in about 2 dozen more packages when installed and by the names primarily python and qt4 support. While trying to get the Rescheduler docked I accidentally clicked on the Boinc Manager in the Dock and suddenly it launched and connected to the client and started running tasks normally.

So I surmise that at least one of those two dozen packages I installed for the Rescheduler provided the missing support to Boinc Manager to connect to the client. Whatever it was is already loaded in the default 16.04/Unity distribution but missing initially in the Ubuntu 18.04/Gnome distribution.

I sure would like to know what package or packages I installed was the likely culprit that enable Boinc Manager to dock and execute properly from the dock.

Just to make sure you understand, all the needed dependencies for BOINC were already installed and functioning before this. BOINC was running fine from its folder when double clicked to start.

Hopefully this helps. I sort have this issue sometimes.

Here is what I do -

First see what is running. I use System Monitor to see if the processes "boinc" and/or "boincmgr" are running. For simplicity, "end task" for whatever is running.

"boinc" must be running before "boincmgr" is started.

Second, start "boinc". Go to Terminal and enter /etc/init.d/boinc-client start

Third, start boincmgr. There are several ways to do that.

If "boinc" is running, and boincmgr" shows disconnected in the bottom panel, stop "boincmgr", and restart it.


I think there is a "timing problem" between "boinc" and "boincmgr"when booting the computer sometimes.

The Linux boinc client is started as a systemd script (depending on your Linux flavour). It runs under the boinc users account. The manager cannot start it. You can however stop it via the manager if you tick the terminate option on the exit dialogue. Once its terminated you'll have to start the service to get it going again.

As Bob has said the client has to be running before the manager can connect to it. Under normal circumstances it would be started when the system boots up.

Typical commands:
sudo service boinc-client stop - Stop the service
sudo service boinc-client start - Starts the service
sudo service boinc-client status - Query its status

---

MarkJ

I don't use the repository version of BOINC so no boinc-client. Just boinc and boincmgr. Starting the Manager automatically starts the client on my version of Boinc.

Keith, this forum.

Please copy-paste the BOINC .desktop file here.

Did you have BOINC client already running when you tried to open Manager with .desktop file?

I don't use the repository version of BOINC so no boinc-client. Just boinc and boincmgr. Starting the Manager automatically starts the client on my version of Boinc.

Then there's something different about your manager link. In Linux, the manager only opens the manager, never the client. When installed as a package the client auto starts with Linux, at least Debian based versions.

I've just copied the app_info and executable from the SETI cuda90 download and put it into my normal SETI folder and its worked fine. I've used the 7.9.3 package install with 18.04 and previous versions on older debian installs. No need for the full BOINC setup from SETI custom apps.

Keith, this forum.

Please copy-paste the BOINC .desktop file here.

Did you have BOINC client already running when you tried to open Manager with .desktop file?

Hi Juha. Thanks for checking in.

This is my 16.04 .desktop file that I copied over from one of my 16.04 machines. It allowed me to me to dock the manager. But the Manager only opened its window and never connected to the client.

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=BOINC Manager
Icon=/home/keith/Desktop/BOINC/boincmgr.32x32.png
Path=/home/keith/Desktop/BOINC
Exec=/home/keith/Desktop/BOINC/boincmgr
StartupNotify=false
StartupWMClass=Boincmgr
OnlyShowIn=Unity;
X-UnityGenerated=true

Then when I added these packages later:
libblas3 (3.7.1-4ubuntu1)
libgfortran4 (7.3.0-16ubuntu3)
liblapack3 (3.7.1-4ubuntu1)
python-numpy (1:1.13.3-2ubuntu1)

libmng2 (2.0.2-0ubuntu3)
libmysqlclient20 (5.7.22-0ubuntu18.04.1)
libqt4-dbus (4:4.8.7+dfsg-7ubuntu1)
libqt4-declarative (4:4.8.7+dfsg-7ubuntu1)
libqt4-designer (4:4.8.7+dfsg-7ubuntu1)
libqt4-help (4:4.8.7+dfsg-7ubuntu1)
libqt4-network (4:4.8.7+dfsg-7ubuntu1)
libqt4-script (4:4.8.7+dfsg-7ubuntu1)
libqt4-scripttools (4:4.8.7+dfsg-7ubuntu1)
libqt4-sql (4:4.8.7+dfsg-7ubuntu1)
libqt4-sql-mysql (4:4.8.7+dfsg-7ubuntu1)
libqt4-svg (4:4.8.7+dfsg-7ubuntu1)
libqt4-test (4:4.8.7+dfsg-7ubuntu1)
libqt4-xml (4:4.8.7+dfsg-7ubuntu1)
libqt4-xmlpatterns (4:4.8.7+dfsg-7ubuntu1)
libqtassistantclient4 (4.6.3-7build1)
libqtcore4 (4:4.8.7+dfsg-7ubuntu1)
libqtdbus4 (4:4.8.7+dfsg-7ubuntu1)
libqtgui4 (4:4.8.7+dfsg-7ubuntu1)
mysql-common (5.8+1.0.4)
python-qt4 (4.12.1+dfsg-2)
python-sip (4.19.7+dfsg-1)
qdbus (4:4.8.7+dfsg-7ubuntu1)
qt-at-spi (0.4.0-8)
qtchooser (64-ga1b6736-5)
qtcore4-l10n (4:4.8.7+dfsg-7ubuntu1)
libxdo3 (1:3.20160805.1-3)
xdotool (1:3.20160805.1-3)

Boinc started working correctly for me when I found accidentally that the Manager window opened and connected to the client after those packages were installed.

I installed the python-numpy and xdotool packages for the Rescheduler and they pulled in all those other support packages. So one of those packages flicked the switch somehow to get the Manager to connect to the client when launched from the Dock.

Boinc ran normally for me since first installation on this new 18.04 LTS machine when launched from its own folder from the get go. Only the dock problem was new with 18.04 LTS.

I don't use the repository version of BOINC so no boinc-client. Just boinc and boincmgr. Starting the Manager automatically starts the client on my version of Boinc.

Then there's something different about your manager link. In Linux, the manager only opens the manager, never the client. When installed as a package the client auto starts with Linux, at least Debian based versions.

I've just copied the app_info and executable from the SETI cuda90 download and put it into my normal SETI folder and its worked fine. I've used the 7.9.3 package install with 18.04 and previous versions on older debian installs. No need for the full BOINC setup from SETI custom apps.

The manager link hadn't even been installed yet. There was none created with my BOINC. But the Manager and client start normally always for me by just clicking on the manager executable icon in its folder.

I will repeat one more time for you. I don't ever install or use any repository version of Boinc. I use the Tbar 7.4.44 or 7.8.3 Linux versions from Crunchers Anonymous.

This is my 16.04 .desktop file that I copied over from one of my 16.04 machines.

Looks ok. The new packages shouldn't have made any difference. Not sure why it didn't work at first. Manager logs in $HOME/.BOINC/std{out,err}gui.txt might have clues.

This is my 16.04 .desktop file that I copied over from one of my 16.04 machines.

Looks ok. The new packages shouldn't have made any difference. Not sure why it didn't work at first. Manager logs in $HOME/.BOINC/std{out,err}gui.txt might have clues.

The file $HOME/.BOINC/stderrgui.txt was 485MB in size and gedit had trouble loading it because of size. I looked through it but didn't know what I was supposed to be looking for.

So I wouldn't know if it logged anything out of the ordinary or not. Can you tell me what I should be looking for in the file? The stdoutgui.txt file was 0 bytes.

My other identical new 18.04 system's stderrgui.txt was only 66MB in size. That one benefited from my experience with the first one's experience and I had no issue with it docking and launching from the Dock since I had done the prep work to avoid the pitfalls I experienced with the first 18.04 conversion.

So the large 485MB size of the first troublesome system could be just holdover errors from when I was struggling with it.

I was hoping that something would stand out but with that big log nobody's going to read it.

Were the lines in the something like this

Function Start/End: something::something - Function Begin
Function Start/End: something::something - Function End

by any chance?

Anyway, so now it works every time?

I was hoping that something would stand out but with that big log nobody's going to read it.

Were the lines in the something like this

Function Start/End: something::something - Function Begin
Function Start/End: something::something - Function End

by any chance?

Anyway, so now it works every time?

OK, now I know what you were looking for. This is a snippet at the beginning of the log. 450MB of the same followed basically.

02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin
02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin
02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End
02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin
02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End
02:45:27 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End
02:45:27 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:27 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:27 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::SaveState - Function Begin
02:45:28 PM: Trace: (Function Start/End) CBOINCBaseFrame::SaveState - Function Begin
02:45:28 PM: Trace: (Function Start/End) CBOINCBaseFrame::SaveState - Function End
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::SaveWindowDimensions - Function Begin
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::SaveWindowDimensions - Function End
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::SaveState - Function End
02:45:28 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin
02:45:28 PM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End
02:45:28 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End
02:45:28 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:28 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:28 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:29 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:29 PM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin
02:45:29 PM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End
02:45:29 PM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End
02:45:29 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:29 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:29 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:30 PM: Trace: (Function Status) CNetworkConnection::Poll - Reconnection Detected
02:45:30 PM: Trace: (Function Status) CNetworkConnection::Poll - RPC Connection Failed '-107'
02:45:30 PM: Trace: (Function Start/End) CBOINCBaseFrame::ShowConnectionFailedAlert - Function Begin
02:45:30 PM: Trace: (Function Start/End) CBOINCClientManager::IsBOINCCoreRunning - Function Begin
02:45:30 PM: Trace: (Function Status) CBOINCClientManager::IsBOINCCoreRunning - Returning '0'
02:45:30 PM: Trace: (Function Start/End) CBOINCClientManager::IsBOINCCoreRunning - Function End
02:45:30 PM: Trace: (Function Start/End) CMainDocument::StartupBOINCCore - Function Begin
02:45:30 PM: Trace: (Function Start/End) CBOINCClientManager::IsBOINCCoreRunning - Function Begin
02:45:30 PM: Trace: (Function Status) CBOINCClientManager::IsBOINCCoreRunning - Returning '0'
02:45:30 PM: Trace: (Function Start/End) CBOINCClientManager::IsBOINCCoreRunning - Function End
02:45:30 PM: Trace: (Function Status) CMainDocument::StartupBOINCCore - szExecute '/home/keith/Desktop/BOINC/boinc --redirectio --launched_by_manager'

02:45:30 PM: Trace: (Function Status) CMainDocument::StartupBOINCCore - szDataDirectory '/home/keith/Desktop/BOINC/'

I think the Reconnection Detected and the RPC Connection Failed -107 is the part you are probably interested in. I don't know, I am not a programmer.

And yes, to your question, it works every time now. I can undock the Manager and put it back again and it will launch the manager and client normally. So again, coincidence or not, what changed the outcome was the loading of all those python packages for the other application. Or BOINC sorted itself out on its own. I would have to duplicate exactly the same software build on a new machine again to see if it happened again in the same exact way.

You found a good part of the log but cut it a bit short. There might have been an error message some number of messages later.

That excessive logging is because you are running an old version. It's has been fixed in newer versions.

I'll go back again and look but I scanned through about a third of the file from the beginning and never saw an error message.

I peeked at the source code and Manager itself doesn't log error messages, at least not where it's starting the client. Any error message would come from system. If there is an error message it would be very near StartupBOINCCore messages.