|
1)
Message boards :
Server programs :
mariadb index limitaion (ERROR 1071 (42000))
(Message 91298)
Posted 30 Apr 2019 by ChristianB Post: It's in general not a good idea to start a DB with latin1 nowadays. Tis is one thing you can't easily change afterwards. The problem on Debian buster is that they use utf8mb4 as the default whereas BOINC just needs utf8 to work correctly. So if you still can please change to UTF8 (without the mb4). |
|
2)
Message boards :
BOINC client :
7.14.2 and 7.12.1 both fail to get work units on very fast systems
(Message 91264)
Posted 29 Apr 2019 by ChristianB Post: As a sidenote: there are some more interesting metrics that paint a better picture of the "throughput" of a project that are not shown on the SSP. One of them is the number of validated workunits per day which can be gathered from the validator logfile by counting specific lines using a grep command. The number of "satisfied" and "unsatisfied" work requests is also nice to have but not so easy to gather as this is in the scheduler log and not easily correlated (at least EaH hasn't found an easy way). |
|
3)
Message boards :
BOINC client :
7.14.2 and 7.12.1 both fail to get work units on very fast systems
(Message 91262)
Posted 29 Apr 2019 by ChristianB Post: This really looks like a server issue to me. When I had this kind of problem on Einstein@home what usually helped was looking at the scheduler logfile of the server which can be made more verbose and print out reasons why certain work was or was not chosen for a host. What I didn't read in this thread is if the limits (per GPU, per CPU and total) are reached or not. That would be my first guess that can be easily checked on the server. The other thing that may cause this is that the demand for each MW application is different and so the space in the shared memory array that the feeder accesses needs to be divided according to demand. This is done by setting the priority for each application by the project administrator. After restarting the feeder and scheduler (if run as FCGI) there might be more room for the application in high demand. Another metric that the administrator should look at is the number of tasks added to the shared memory array with each feeder run (every 5 sec). If you fill up the whole array each time you need to make it bigger or your tasks longer. If the array is not drained quickly but users complain about "0 tasks sent" than there must be something else wrong in how the scheduler finds work for a host with a work request (back to looking at the scheduler log and requests from hosts that show this problem). |
|
4)
Message boards :
Server programs :
Daemons not starting
(Message 91223)
Posted 26 Apr 2019 by ChristianB Post: Please take a look at the logfiles of the daemons. They are on the server in your project root directory in a folder called logs_(hostname). The project start script just tries to start them if there are startuperrors they appear in the logfile. Also you could try to run the daemon command yourself (as boincadm) and see what it is complaining about. |
|
5)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91073)
Posted 12 Apr 2019 by ChristianB Post: ...there is a different "UAC" system (visual sudo) in every distribution...Users say they only know of gksudo, and it was deprecated in Ubuntu from 18.04 Rephrasing: Every distribution has a different way for a graphical program to gain su permissions. As stated in the bug you quoted the gksu executable was replaced by two different other approaches for a GUI to elevate privileges. It would be a nightmare for a BOINC developer to maintain all those possibilities. What I can see in the Seti Thread is that the Power Users tend to use self built standalone installations in /home and do not use a service install. For those use cases the Client can be started by the Manager because the Client needs to be started by the user. In the case where the Client was installed by the package manager that is different. Here is how I understood the initial question about removing the ability from the Manager to stop the Client: When BOINC is installed by a package manager the Manager itself cannot start the Client but it can stop it. So when the user exits the Manager and for whatever reason chooses to shutdown the Client it will stay off until the service or the computer is restarted because no matter how often you start the Manager it can not start the Client. 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. |
|
6)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91070)
Posted 12 Apr 2019 by ChristianB Post: Starting the client in service mode, under a different user security regime, is the only time that the Manager has to work with operating system security protocols - and I think that applies equally to Windows and Linux. Exactly. That is the point I wanted to bring across. On Windows this is solved by asking the user if this action (starting a service) is permitted (you see the UAC screen). On Linux you can also do this of course but there is a different "UAC" system (visual sudo) in every distribution and of course the command to start/restart/stop is different on each distribution depending which init system is used. That makes it harder to achieve the same functionality for a service installation on Linux. The only real problem is really in starting the Client. All other actions like snoozing science apps suspending/resuming or stopping the Client altogether are done using RPC from Manager to Client. But starting the Client as a service when installed via package manager is the hard problem. |
|
7)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91068)
Posted 12 Apr 2019 by ChristianB Post: This is not a questions or discussion about splitting the installation on Linux as this has already happened and is a requirement by most Linux distributions. This is also not a problem for normal users and power users. The normal user installs both packages (usually without knowing there are two packages) and the power user that runs 24/7 headless machines only installs the Client package. That is already possible and not a challenge for the developers or the users. What is the challenge and the reason for Richards question is whether the Manager should behave the same on Windows and Linux. Especially when it comes to starting and stopping the Client (and thus the science applications). AS I described there are some limitations on Linux that hinder the Manager from doing the same things the Manager does on Windows. Focusing on the top 5 Linux distributions is basically what the BOINC software project already does, since there is no standalone installer anymore. |
|
8)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91066)
Posted 12 Apr 2019 by ChristianB Post: One other useful information in this context is whether the majority of Linux users are using the packages provided by their distribution or self compiled executables. This is in essence a discussion about different policies on different platforms and whether BOINC should behave the same on all platforms. There are two policies or modes that are either or and they can be followed on all platforms. The first is "user mode" and this means that the Client and the Manager run under the context of the currently logged in user. The second is "service mode" and it means that the Client runs under a different context (account) than the Manager. This is not specific to any platform but now it gets tricky on how those modes are implemented in each platform. I'm going to discuss Windows and Linux although Mac behaves roughly the same as Linux. On Windows there is one Installer file that installs the Client and the Manager. This hides the complexity of the program from the user and is intentional. The user has the choice of installing the Client using his personal account or as a service that runs in the background without the user needing to login and start the manager. We'll just ignore the fact that in both cases the installer creates special accounts that are used to sandbox the scientific application so that they can't access files outside the BOINC data directory since that has nothing to do with the two modes I described. On Windows the Manager is always started using the currently logged in user and thus is always able to interact with the client because it can start the Client in both modes and the Client will run in the context of the special account that does the sandboxing. Linux follows a different policy regarding installation packages. They are usually broken into components that can exist individually. In the case of BOINC it means you can install the Client without the Manager and vice versa. Linux also follows a more stricter sandboxing policy which limits privilege escalation. For a normal user it's not possible to run an executable as a different user. That right is limited to the root account. And this is the main difference between Windows and Linux that is relevant for this discussion. Re-read the above paragraph about Windows and now see how this is different on Linux. On Linux the Client and Manager when installed via the distribution package system are installed using the root account and there usually is a special account for running the Client created (to sandbox the app and also allow it starting as a service). Since this service is not running as the currently logged in user only the root user can control this service. Since the Manager is started as the currently logged in user (which is not the root user!) it can not interact with the service. What it can do is tell a running Client that it should quit using another mechanism that is not relevant here. So in essence: a "service mode" installation on Linux does not behave like one on Windows because the operating system doesn't offer the same possibilities. A "user mode" installation on Linux is also possible and was done using a downloadable file from the BOINC software project but this file was not updated a long time (6 years) so the only way to have a recent "user mode" installer is by self compiling one. Then the above restrictions don't apply but also the security benefits don't come into play and the Client and the Manager run as the logged in user. This is not advisable. What I would like to know is how many users are running "user mode" installations on Linux? Why are they doing this? What can we do to reduce this number and switch people over to the "service mode" on Linux? P.S.: Don't hesitate to ask questions if you don't understand the above and I'll explain better. |
|
9)
Message boards :
BOINC Manager :
English display in French version
(Message 88508)
Posted 18 Oct 2018 by ChristianB Post: #ifdef THESE_STRINGS_ARE_FOR_GETTEXT ? Yes, that works. The gettext parser ignores those. |
|
10)
Message boards :
BOINC Manager :
English display in French version
(Message 88506)
Posted 18 Oct 2018 by ChristianB Post: Interesting thought. We could just add the basic strings to CBOINCGUIApp::SafeMessageBox(...) like this:
int CBOINCGUIApp::SafeMessageBox(const wxString& message, const wxString& caption, long style,
wxWindow *parent, int x, int y )
{
int retval;
wxString d1 = _("OK") + _("Cancel") + _("Yes") + _("No");
m_bSafeMessageBoxDisplayed++;
retval = wxMessageBox(message, caption, style, parent, x, y);
m_bSafeMessageBoxDisplayed--;
return retval;
}
This will most likely trigger an unused variable warning but that can be handled later. |
|
11)
Message boards :
BOINC Manager :
English display in French version
(Message 88501)
Posted 17 Oct 2018 by ChristianB Post: I agree with Richard. It seems better to replace wxMessageBox with wxMessageDialog like in the Trac ticket I linked too. This would look like this in our case I think:
int CBOINCGUIApp::SafeMessageBox(const wxString& message, const wxString& caption, long style,
wxWindow *parent, int x, int y )
{
int retval;
m_bSafeMessageBoxDisplayed++;
wxPoint pos(...);
wxMessageDialog dlg(parent, message, caption, style, pos);
if (style contains wxOK) { //not sure is this is needed
dlg.SetOKLabel(_("OK"));
}
retval = dlg.ShowModal();
m_bSafeMessageBoxDisplayed--;
return retval;
}
I'm not sure if we need to test the styles used or if we could simply override all buttons even if they are not used. That must be tested. |
|
12)
Message boards :
BOINC Manager :
English display in French version
(Message 88456)
Posted 15 Oct 2018 by ChristianB Post: This seems to be an old problem: https://trac.wxwidgets.org/ticket/10962 but the bug report claims that this is fixed since wxWidgets 2.9 The place where this is called is: https://github.com/BOINC/boinc/blob/f368579c547c15a9bea0d3c0b6c235ae32123410/clientgui/BOINCGUIApp.cpp#L1268 So this should affect the cancel result dialog too. The real problem might be that we don't ship the default wxWidgets translation files "wxstd.mo". I found the files for wxWidgets 3.1: https://www.wxwidgets.org/about/translations/ but all I could find for 3.0 is this: |
|
13)
Message boards :
BOINC client :
Authorization Failure -155
(Message 87686)
Posted 17 Aug 2018 by ChristianB Post: When using boinccmd on Linux it is important from where you execute the command. So without your working directory at the time you execute the command we can't help you. What boinccmd does is look in the current directory for a file called "gui_rpc_auth.cfg" to read the password from. See: https://boinc.berkeley.edu/wiki/Boinccmd_tool If you run boinccmd in the same directory as the BOINC client, you don't need to supply either a host name or a password. |
|
14)
Message boards :
Server programs :
Boinc Manager cannot connect to own boinc vm
(Message 87610)
Posted 13 Aug 2018 by ChristianB Post: I suspected as much. We should definitely get rid of this dependency or at least have an easy way to detect an inconsistency there. |
|
15)
Message boards :
Server programs :
Boinc Manager cannot connect to own boinc vm
(Message 87580)
Posted 11 Aug 2018 by ChristianB Post: This is probably a problem with how you setup your project. When running make_project on the server it uses the current IP of the server to create the project. This IP is added in several places and later send to clients when they connect. If the client then can't reach the IP it fails with the errors you describe. So in short you should check on the server what values are set in config.xml as master_url and what is in html/user/scheduler.txt. You need to make sure that the correct information is in those files. Ideally both would contain the "public" IP of the server or a servername that can be resolved by your clients. This part depends on whether you want your project to be public (reachable via Internet) or company internal. Please note that changing the master_url is not easily possible for public facing projects. |
|
16)
Message boards :
Server programs :
create_work: unexpected XML tag or syntax
(Message 87163)
Posted 18 Jul 2018 by ChristianB Post: If you don't have an input file you need to remove it from the input template. Simple as that. But then every workunit created will do the same calculations. You somehow need to parameterize the work. In your simple case that would maybe mean that workunit_1 calculates fib(1), workunit_2 fib(2) and so on. How should the executable on the client computer know which part of your parameter space it should work on. The simplest case is via input file another is via commandline but than you need to alter the create_work call for every workunit which is harder to do. |
|
17)
Message boards :
Server programs :
How many task(slots directories)would be generated when i have only one work_unit and only one client computer?
(Message 81935)
Posted 11 Oct 2017 by ChristianB Post: Depends on the minimum quorum you set in https://boinc.berkeley.edu/trac/wiki/JobIn. The first part is correct. The last part not. Whether both tasks of a workunit can be run on the same computer is set in config.xml by the options <one_result_per_user_per_wu/> and <one_result_per_host_per_wu/> see: http://boinc.berkeley.edu/trac/wiki/ProjectOptions#Joblimits this is to ensure that a malicious client can not tamper both results of a single workunit. |
|
18)
Message boards :
API :
How should I edit the input_template if i have a huge amount of input files?
(Message 81887)
Posted 9 Oct 2017 by ChristianB Post: Information about templates can be found here: http://boinc.berkeley.edu/trac/wiki/JobTemplates Please post your existing templates so I can help you. Downloading 1.5TB for a single workunit seems very inefficient. How long does one task run? You want to keep the ratio of download traffic per CPU second at a reasonable range or you spent more time sending data around then computing it. You will also most likely reach a limit on network bandwidth on your download server if several clients download the input files at once. |
|
19)
Message boards :
Server programs :
version.xml under applicaion folder is not downloaded seeing from the client side
(Message 81886)
Posted 9 Oct 2017 by ChristianB Post: The version.xml file is just a meta information for update_versions it is not supposed to be present on the client. All information is added to the DB and gets send to the client as part of the application version information. Why do you need the file on the client? (see: http://boinc.berkeley.edu/trac/wiki/AppVersionNew) so the stderr_txt is can not read job.xml.I don't understand. I think you mean that in stderr.txt the wrapper complains that it can't read a file called job.xml. Please take a look at how BOINC references files: http://boinc.berkeley.edu/trac/wiki/BoincFiles. For the wrapper please read http://boinc.berkeley.edu/trac/wiki/WrapperApp where it says that you need a file with the logical name "job.xml". I guess your version.xml is setup wrong or you are changing the content of files without renaming them. Regards Christian |
|
20)
Message boards :
Server programs :
issues in starting "daemons" while settin up boin server
(Message 81679)
Posted 2 Oct 2017 by ChristianB Post: This looks like the project directory in your config.xml is wrong. But I'm not sure. Please contact the Debian maintainer of the boinc-server-maker package or look at the troubleshooting section of the ServerGuide page. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.