I've found the stdoutdea.txt file. It is quite big.

Should I truncate the file, restart BOINC and wait for the fail state to occur again?

That would give me a cleaner file to look at.

Note: The file contains a lot of "Can't create link file" errors on 2 of the projects, one in particular. Einstein@Home.

This is getting so annoying.

It did it again today, but the event log was greyed out again.
I restarted the BOINC manager and everything came back up, but the event log contains nothing before me restarting it.

Okay, this has just happened again on the same day.

Again, the event log option is greyed out.

I know it's a communications clash between the graphical front end, BOINC Manager and the Daemon.

How do I test for this failure and force both sides to cleanly shut down and reboot?

It's just done it again and again and again

I've had enough.

I've created a script to test if the boinc-client daemon is running, and if it's not running, then restart the daemon.
I've stuck that into crontab and it's running the script every five minutes, testing and restarting as necessary.

If the daemon is not running, cron restarts boinc-client and then restarts the boincmgr 2 seconds later.

I still have no idea why the daemon is dropping out.

I still have no idea why the daemon is dropping out.

And you still haven't given any information that will let those with more knowledge than I do help you. At the moment, your only hope is that someone else has had the same problem and solved it for themselves.

Look for the entry that matches the time when it drops out in stdoutdea.txt file and post the dozen or so entries around that time.

I still have no idea why the daemon is dropping out.

And you still haven't given any information that will let those with more knowledge than I do help you. At the moment, your only hope is that someone else has had the same problem and solved it for themselves.

Look for the entries that matches the time when it drops out in stdoutdea.txt file and post the dozen or so entries around that time.

I am finding that the stdoutdea.txt is now empty, which really does not help at all.
It isn't supposed to be.

I just had to write a script to reboot the boinc-client daemon when it drops out,
which I place into crontab, checking every 5 minutes for dropouts.

But then the boincmgr was refusing to reconnect to the daemon, so I had to create a user service to reboot the GUI as well.
Had to be user service because it refused to connect to my screen.

It is kind of working now, but not the way it's meant to.

The annoying thing is, this was all working right up until a day or two before I made the original post back on December 13.

Well, it's now gone 2:00 am in the morning, and my brain hurts.
I'm going to bed.
I've had enough.

Why don't you just run the client in a terminal without worrying about the Manager. The client output will print in the terminal allowing you see its startup and supposed dropout. Then post what that printout shows.

Everything that prints in the terminal is what ends up in the stdoutdae.txt file, otherwise known as the Event Log in the Manager.

I wonder if it's related to the problem noted in BOINC Manager closes when viewing notices (Issue #6784)
GIT issue 6784
FlitPix left a comment:

Setting GDK_BACKEND=x11 WEBKIT_DISABLE_COMPOSITING_MODE=1 fixes this, as well as another issue where synchronizing with an account manager fails to open the confirmation window.

I think my own post here makes post 30 and I don't see a single line from the event log or from the file. I'm guessing gui_rpc_debug would be one to turn on.

I use the Linux mgr maybe once at most during initial install on any given PC so I don't use it. Then I use BOINCTasks from my Win10 main computer. Looks like it would only be available via Wine if you want it on that PC.

I wrote above:

On Linux you can find this logs by running 'journalctl' command

and since then I haven't received any information about the logs from it.
'journalct' is the central place on Linux for logs, and boinc does logs there as well.
That is why in the txt log files there is no data (also, the other reason is because boinc client is running as a daemon under a separate user).

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

I can easily see the gui at a glance and know if things have dropped out or gone wrong.

Not so easy in a terminal window

If the gui wasn't showing a problem, I'd never have known there was one.

I've forced the daemon to log all of its errors to file: /var/lib/boinc-client/boinc-client.log
It didn't seem to want to use stderrdae.txt

I tracked the problem down to the OOM, it was killing off the boinc-client.

I've increased the swapfile 4 fold in size.
Interestingly, this laptop has been running for 3 years and the problem only started happening in December.
I'll keep monitoring it.

[Service]
OOMScoreAdjust=-500
StandardOutput=append:/var/lib/boinc-client/boinc-client.log
StandardError=append:/var/lib/boinc-client/boinc-client.log

Well, it's been well over a week, and I've had no further problems.

So, that looks like the answer: the Linux Out-of-Memory (OOM) killer was killing off the Daemon.

I had no idea that that even existed.

Still, I don't understand why it worked perfectly well for 3 years before having a problem.

I guess this issue is now closed.