Anybody got something other than 2 GPUs running MW in 1 host that can tell me what their limit is?

The word native contains the letters ATI, and that's what triggers the false positive GPU report.

A prior post suggested there may be no way to check if the option was activated. When I run:

cat /usr/src/linux-headers-$(uname -r)/.config | grep

I get:

cat: /usr/src/linux-headers-4.19.0-6-amd64/.config: No such file or directory

even though I should have activated it in grub with:

GRUB_CMDLINE_LINUX_DEFAULT="vsyscall=emulate"

and:

sudo update-grub

grep VSYSCALL /boot/config-$(uname -r)

This is likely a moot point as some pretty knowledgeable people have told me the issue I am trying to resolve is likely not with the vsyscall at all.

I am just trying all options in order of complexity

What does

cat /usr/src/linux-headers-$(uname -r)/.config | grep VSYSCALL

tell me? I have seen this suggested in a number of posts where they received a reply of

cat /usr/src/linux-headers-$(uname -r)/.config | grep VSYSCALL 
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_X86_VSYSCALL_EMULATION=y
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set

I added to grub: GRUB_CMDLINE_LINUX_DEFAULT="VSYSCALL=EMULATE"

The grub update seemed to go ok.

For some reason I don’t get the confirmation of the emulation mode.

What I am asking is since this is a known issue, how does one diagnose the cause of the error, memory, OS, BOINC? How did others resolve the issue? I can find dozens of references to the issue, all with a BOINC project, but only two resolutions, where vsyscall was put into emulate mode.

Just add boinc to the render group.

I've already tried that with no result.

apt-get install mesa-opencl-icd
adduser boinc render
systemctl restart boinc-client.service

Mesa OpenCL on a Bonaire GPU can work for Collatz in Debian 9 with files from official reps.

No usable GPUs found

If kill it, and start it the wrong way, via console
$boinc, then

an AMD card is detected (but no Intel) and boinc-manager can't connect to boinc.

And If I'm fine with all security risks from boinc side, what may be done to run the GPU's?

For a long time, there were reports that specific projects wouldn't allow the special 0 value to be entered via their websites.

What happens if a user specifies 0 via an AM, for a project which can't handle it?

BOINC global preferences - including RS - are supposed to be propagated from project to project during client contacts: would a non-updated project substitute unwanted values during that process?

I'll have a look through the client code to see if I can find that "reset if all zero" bug that floyd described

we can lose that now that zero has been ascribed an active meaning

But for the time being (until I find the smoking gun in the code), I'm keeping an open mind

They can also suspend all projects indefinitely, without limit of time - which might be almost as bad as stopping the service.

The 'snooze' action is distinctively different, because it sets a 60 minute timer: BOINC restarts even if the user has left the building. And it's relevant here, because the same Debian developer has also proposed "Disable BOINC Manager system tray icon on Linux platforms". And 'snooze' can only be invoked from the system tray icon.

Stepping carefully into this heated discussion

I think you're conflating multi-user with multi-tasking.

I can't imagine a significant need to take that action from within boincmgr (or boinccmd). Anybody and anything can suspend boinc without any privileges and if it really needs to be stopped or (re-)started, the "responsible" people already have other ways. I would strongly advise against making changes in this sensitive area just to add some rarely used shortcut.

I really don't understand your point here. I thought the purpose of this whole thread was to garner user feedback about a proposal to remove some existing functionality from the manager that allowed a user to stop a boinc client under circumstances where they wouldn't be able to restart it without the ability/knowledge to re-launch the service mechanism that started boinc in the first place

Please correct me if I'm not understanding the purpose of this thread.

If an ordinary 'buntu (or derivative) user needed to restart a client killed through the current manager functionality, all they would need to do is run the command

sudo systemctl restart boinc-client

or something like that.

# This file is /etc/default/boinc-client, it is a configuration file
# for the /etc/init.d/boinc-client init script.

Note that
1) command: "...# journalctl -xe" and
2) command: "...# systemctl status boinc-client"
both show that boinc is stuck in "/var/lib/boinc-client" directory.

Richard, you and ChristianB seem to continue a discussion that started somewhere else. I and probably most people here don't know its history ...

The discussion seems to be here.

Linux has evolved from Unix, so is brilliant as a multi-user system, but it's a bit of hyperbole to suggest that it's fighting against its basic design when used as an extremely capable single user system :-).

For the question of starting the client in a "service" install I second ChristianB, you shouldn't be able to stop what you haven't started.

Except ... you can easily have the best of both worlds by having a simple popup appear that asks for the root password if the user wants to take that action. To my mind this covers both situations - the multi-user environment where only 'responsible' people have that password and the true 'single user is administrator' environment.

I would think that most Linux systems that contribute to BOINC projects fall into the latter category

so I think single user systems need to be catered for

not overly penalised by complete removal of existing functionality

How are you going to restart a remote client that was your (the local user's) only connection to the remote system, and you just killed it?

I'm not sure if I properly understand what you mean but if on my machines, I were to shut down a remote client from a local BOINC Manager, I could easily login over ssh and restart that client immediately.

• Is it worth the effort to implement that, with possible security implications, when there already is a working solution?
  
• Can that work remotely? If it can, do we want to give some unknown (there) gary any control over the remote system? If it can't, do we want BM to behave different when controlling remote systems?
  

The scripts use boinccmd to do all sorts of stuff. I'd be concerned if boinccmd functionality was being removed :-).

Therefore the ability to stop the Client should be removed. There are clear alternatives to just removing the option and I now wonder why they where never mentioned in the github PR or issue.

Here, here. That's why I got involved, and why we're having this discussion.

My feeling is that the advocates of the current issue / PR had a particular (and narrow) view of 'the typical Linux user' - probably guided by the Linux users in their personal workspace - and proposed solutions that seemed natural for that particular stereotypical user.