How to compile xmr-stak (2.10) under CentOS 7 for CPU mining cryptocurrencies in September 2019

A time to refresh our old article on how to compile xmr-stak for CPU mining with the new version and this time a new GNU GCC version (version 8.3, the last article we used 7.x – How to compile xmr-stak (2.4.5) under CentOS 7 for CPU mining cryptocurrencies). Always use the latest available GNU GCC packages because the latest version of GNU GCC could add some optimizations to the binary compiled code and you may have a CPU miner with better performance!
Thanks to xmr-stak we can have one application capable of mining many different cryptocurrencies based on different algorithms. XMR-STAK is GPU and CPU miner and here we present only the CPU ability under CentOS 7 using our AMD Threadripper 1950X.
The software in this article:

  • CentOS 7 – CentOS Linux release 7.6.1810 (Core)
  • GNU GCC – gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)
  • XMR-STAK – 2.10.7

As said many times working with crypto-currency it is mandatory to do the things yourself – do not trust any binary made by someone on the Internet. It is easy to build your miner yourself with the code from the official repository!

So here are the steps to build the XMR-STAK for CPU mining:

STEP 1) Update your system and install the following dependencies

Always start with update command and then install the dependencies in order first install all the new repositories and then the dependency binaries.

sudo yum update -y
sudo yum install -y centos-release-scl epel-release
sudo yum install -y cmake3 devtoolset-8-gcc* hwloc-devel libmicrohttpd-devel openssl openssl-devel make git screen wget

We are going to use GNU GCC 8 to build the XMR-STAK. More on the subject of how to install GNU GCC 8 and what is “devtoolset” here – How to install GNU GCC 8 on CentOS 7.
Keep on reading!

root cannot delete, move or change a file – Operation not permitted or Permission denied – immutable attribute

If you are the root user and some file (files or directories) cannot be deleted, removed, renamed or changed you probably deal with the immutable attribute set on (by a colleague of yours – installation setups tend to not set such attributes).

Here is what it looks like to have such a file

root@srv.remote /etc/apache2/vhosts.d # mv example.com.conf /root/old/apache/
mv: cannot move `example.com.conf' to `/root/old/apache/example.com.conf': Operation not permitted
root@srv.remote /etc/apache2/vhosts.d # lsattr example.com.conf
----i--------e- example.com.conf
root@srv.remote /etc/apache2/vhosts.d # rm example.com.conf
rm: cannot remove `example.com.conf': Operation not permitted
root@srv.remote /etc/apache2/vhosts.d # echo "teeest" >> example.com.conf
-bash: example.com.conf: Permission denied

Here is how you can set the attribute off.

You need first to set off the file’s immutable attribute and then to do whatever you intended to do in the first place – delete, rename, change and so on. Y

chattr -i filename.txt

In continuation of our example above:

root@srv.remote /etc/apache2/vhosts.d # chattr -i example.com.conf
root@srv.remote /etc/apache2/vhosts.d # lsattr example.com.conf
-------------e- example.com.conf
root@srv.remote /etc/apache2/vhosts.d # mv example.com.conf /root/old/apache/
root@srv.remote /etc/apache2/vhosts.d #

As you can see no immutable attribute no problem to move the file!

And just not note you need to install a package with the name e2fsprogs (not always in the default installation) in your Linux distribution to have lsattr, chattr and more!

Really bad performance when going from Write-Back to Write-Through in a LSI controller

Ever wonder what is the impact of write-through of an LSI controller in a real-world streaming server? Have no wonder anymore!

you can get several (multiple?) times slower with the write-through mode than if your controller were using the write-back mode of the cache

And it could happen any moment because when charging the battery of the LSI controller and you have set “No Write Cache if Bad BBU” the write-through would kick in. Of course, you can make a schedule for the battery charging/discharging process, but in general, it will happen and it will hurt your IO performance a lot!

In simple words a write operation is successful only if the controller confirms the write operation on all disks, no matter the data has already been in the cache.

This mode puts pressure on the disks and Write-Through is a known destroyer of hard disks! You can read a lot of administrator’s feedback on the Internet about crashed disks using write-through mode (and sometimes several simultaneously on one machine losing all your data even it would have redundancy with some of the RAID setups like RAID1, RAID5, RAID6, RAID10 and so).

srv ~ # sudo megacli -ldinfo -lall -aall
                                     
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :system
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 13.781 TB
Sector Size         : 512
Mirror Data         : 13.781 TB
State               : Optimal
Strip Size          : 128 KB
Number Of Drives per span:2
Span Depth          : 6
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Bad Blocks Exist: No
Is VD Cached: Yes
Cache Cade Type : Read Only

Exit Code: 0x00

As you can see our default cache policy is WriteBack and “No Write Cache if Bad BBU”, the BBU is not bad, but charging!
Keep on reading!

PHP 7.2 or PHP 7.3 with mcrypt – manual build

Newer PHP versions do not include PHP mcrypt library. The mcrypt module was part of PHP 5 till 7.1, in which it was deprecated and removed in 7.2. If you open the php.net documentation for mcrypt PHP functions you will see:

This function has been DEPRECATED as of PHP 7.1.0 and REMOVED as of PHP 7.2.0. Relying on this function is highly discouraged.

The mcrypt module is now in PHP PECL (repository for PHP Extensions) in https://pecl.php.net/package/mcrypt. As you can see in the description, this is a legacy module, which

Provides bindings for the unmaintained libmcrypt.

, so it is strongly recommended to replace it with OpenSSL (for example).
Still, if you need this legacy module – mcrypt and :

You may want to manually build the mcrypt module for your current installed PHP. Of course, the generic dependencies are:

  1. libmcrypt and its headers (if the Linux distribution) splits the binary and the headers
  2. GNU GCC
  3. PHP 7.2+
  4. download the latest mcrypt module source from https://pecl.php.net/package/mcrypt. For example, now it is https://pecl.php.net/get/mcrypt-1.0.2.tgz
mkdir /root/mcrypt-php-module-manual
cd /root/mcrypt-php-module-manual
wget https://pecl.php.net/get/mcrypt-1.0.2.tgz
tar xzf mcrypt-1.0.2.tgz
cd mcrypt-1.0.2
phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make
make install

Do not use “make -j N” (“make -j 8”, for example), because it may fail to compile.
Keep on reading!

using portage eix for the first time – cannot open database file

Installing “app-portage/eix” in Gentoo to manage your portage updates you might encounter this error, when trying to use “eix” for the first time:

Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')

The chances are missing directory “/var/cache/eix/” or the user:group of the “/var/cache/eix/” is root:root, which is NOT right.

The user:group must be “portage:portage”.

So the solution is really simple:

mkdir -p /var/cache/eix
chown portage:portage /var/cache/eix

Output – the errors you might get

Using the eix-sync failed with:

root@srv1 ~ # eix-sync 
 * eix-cache does not exist
 * Running eix-update
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')
 * eix-update failed
 * Time statistics:
     6 seconds for initial eix-update
     6 seconds total

Using the “eix-update” failed, too.

root@srv ~ # eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')

Output 2 – Successful update with eix

root@srv ~ # eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
Database contains 19544 packages in 167 categories

Kernel loads only single processor on multi-processor system – ACPI: x2apic entry ignored

There multiple reports on this issue with different processors

kernel, which worked perfectly on multiple systems, loads on our new server and only one processor is shown

Just for the record, the SMP is enabled in the kernel (and in the BIOS – Hyperthreading and multicores are enabled, too):

root@srv ~ # zcat /proc/config.gz | grep 'CONFIG_SMP'
CONFIG_SMP=y

The problem is x2APIC Support in the BIOS of your server.

Apparently, our kernel (version 4.18.12) missed the kernel feature:

root@srv ~ # zcat /proc/config.gz | grep -i 'x2apic'
root@srv

You can see no kernel configuration entry “CONFIG_X86_X2APIC=y” is shown from the above command.

And if your BIOS enables the support of x2APIC you may end up with just one processor under Linux.

This was the case in our server. The x2APIC support is enabled in the BIOS and our kernel (version 4.18.12) does not have CONFIG_X86_X2APIC enabled.
To fix this issue you first might disable the feature in the BIOS and you are going to have all your processors shown and they could be used to compile fast your new kernel (of course, in the case you use custom kernel) after you enable the feature in the kernel CONFIG_X86_X2APIC, which is under
Kernel Configuration —> [*] Support x2apic. The asterisk means it is enabled, so build your kernel. Check and enable this “Device Drivers –> IOMMU Hardware Support –> Support for Interrupt Remapping”, too.
Here you can see how to enable and disable processor x2APIC support in HP ProLiant DL160 Gen9 (2 processors Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz) – Enable or Disable the processor x2APIC support in HP ProLiant DL160 Gen9.
Keep on reading!

bind – dns server queries statistics with statistics-file

There is an option “statistics-file” in the BIND9 configuration for query statistics. It will give you statistics for

  • Incoming Requests – total number of queries
  • Incoming Queries – queries by record type
  • Outgoing Queries – queries by record type per view
  • Name Server Statistics – extended queries statistics by network connection type (UDP, TCP or IPv4 and IPv6 interface), by type of answer (authoritative, non authoritative and so on) and more
  • Zone Maintenance Statistics – transfer and system queries
  • Resolver Statistics – recursive queries
  • Cache DB RRsets – cached resources records sets
  • Socket I/O Statistics – statistics numbers for UDP, TCP (for both IPv4 and IPV6) sockets and connections opened, closed, failure
  • Per Zone Query Statistics – so you can see how many queries you have for a zone in a view (and the transfers if the server is a slave)

In named.conf:

options {
....
    statistics-file "/var/log/named.stats";
    zone-statistics yes ;
....

But if you check in /var/log this file might be missing even your BIND server has been running for months!

This is because the statistics and the file is generated on request and is a snapshot at the moment you do the request

To request from the BIND server to generate the file is pretty easy:

root@srv ~ # rndc stats
root@srv ~ #

No standard output and you should have the stats file generated:

root@srv ~ # ls -altr /var/log/named.stats 
-rw-r--r-- 1 named named 174997 Apr  7 01:43 /var/log/named.stats

The generated requests are appended in the file with a UNIX timestamp.

....
--- Statistics Dump --- (1550561292)
+++ Statistics Dump +++ (1551233218)
....

Keep on reading!

Gentoo kde-frameworks/kdewebkit failed compilation with Qt5WebKit could not be found because dependency is required

Updating the KDE Plasma Desktop in our Gentoo workstations this time failed with

CMake Error at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:48 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake

  but it set Qt5WebKit_FOUND to FALSE so package "Qt5WebKit" is considered to
  be NOT FOUND.  Reason given by package:

  Qt5WebKit could not be found because dependency is required to have exact
  version 5.11.x.

It was strange because the previous emerge included the QT upgrade from old 5.11.2 to 5.12.1 and this dependency should have been resolved properly before:

emerge -vau $(qlist -IC|grep dev-qt|sort|uniq)

But apparently despite that the emerge built all QT libraries in dependency order the “dev-qt/qtwebkit” was built against the old QT libraries. And this is what is saying the above error!

The solution is really simple just rebuild the dev-qt/qtwebkit

root@srv ~ # emerge -va dev-qt/qtwebkit

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo  USE="X geolocation hyphen jit multimedia opengl printsupport qml -gles2 -gstreamer -nsplugin 
-orientation -webp" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] yes

Keep on reading!

Installing and running BOINC client (with SETI project) under CentOS 7

Here is how you can install a BOINC client and attach it to a project (SETI). We use only command line tools, not GUI involved here. You can attach to a project and do some various administrative work with

boinccmd

like to get the progress of the currently running project tasks, project info, manage tasks and more.
Steps to install and run a (SETI) project:

STEP 1) Install BOINC client

The installation of the BOINC client requires using EPEL repository. Become root user and install Epel repository and Boinc client.

sudo su
yum update -y
yum install -y epel-release
yum install -y boinc-client
systemctl start boinc-client
systemctl enable boinc-client

STEP 2) Attach to a project

Here we use our SETI project to attach the server to it. There are two ways to attach to a project:

  • Using URL project and account key (strong or weak – it works with both). You can get your account keys from the site project url.
  • Using URL project and account info – username and password

To attach to a project your boinc client must be up and running and to use boinccmd – The command line interface to the BOINC client:

boinccmd --project_attach "http://setiathome.berkeley.edu/" "111111_22222233333344444444444555555555"

The first argument of “–project_attach” is the URL address of the project site, in this case, SETI with “http://setiathome.berkeley.edu/” and the account key of our account is 111111_22222233333344444444444555555555 (this is not the real one!). After successful attach your client will start to download the project files and begin to work on units:

[myuser@compute1 ~]# boinccmd --get_tasks

======== Tasks ========
1) -----------
   name: blc36_2bit_guppi_58406_31023_HIP20352_0115.19579.818.22.45.146.vlar_0
   WU name: blc36_2bit_guppi_58406_31023_HIP20352_0115.19579.818.22.45.146.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:38:07 2019
   report deadline: Sat May 25 18:37:49 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4843.738587
   CPU time at last checkpoint: 1326.038000
   current CPU time: 1366.303000
   fraction done: 0.170349
   swap size: 54 MB
   working set size: 52 MB
2) -----------
   name: blc34_2bit_guppi_58406_26949_HIP20491_0103.21476.0.21.44.1.vlar_1
   WU name: blc34_2bit_guppi_58406_26949_HIP20491_0103.21476.0.21.44.1.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: uninitialized
   active_task_state: UNINITIALIZED
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 5838.283108
3) -----------
 ....

You can see all the tasks – the one running at the moment and those on the queue.
When the “fraction done” reaches 1.0 the tasks is ready to report.

To view all running work units and some useful links in the project site like forums, account, preferences, recent tasks, list of the computers on which you are running SETI@Home, team information and more you can use “–get_simple_gui_info” (some of the data here are changed):

[myuser@compute1 ~]# boinccmd --get_simple_gui_info
======== Projects ========
1) -----------
   name: SETI@home
   master URL: http://setiathome.berkeley.edu/
   user_name: neoX
   team_name: neoX Group
   resource share: 150.000000
   user_total_credit: 14376490.970263
   user_expavg_credit: 25085.116699
   host_total_credit: 0.000000
   host_expavg_credit: 0.000000
   nrpc_failures: 2
   master_fetch_failures: 0
   master fetch pending: no
   scheduler RPC pending: no
   trickle upload pending: no
   attached via Account Manager: no
   ended: no
   suspended via GUI: no
   don't request more work: no
   disk usage: 0.000000
   last RPC: Tue Apr  2 17:19:56 2019

   project files downloaded: 1554212310.422403
GUI URL:
   name: Message boards
   description: Correspond with other users on the SETI@home message boards
   URL: http://setiathome.berkeley.edu/forum_index.php
GUI URL:
   name: Help
   description: Ask questions and report problems
   URL: http://setiathome.berkeley.edu/forum_help_desk.php
GUI URL:
   name: Account
   description: View your account information
   URL: http://setiathome.berkeley.edu/home.php
GUI URL:
   name: Preferences
   description: View and modify your computing preferences
   URL: http://setiathome.berkeley.edu/prefs.php?subset=global
GUI URL:
   name: Tasks
   description: View your recent tasks
   URL: http://setiathome.berkeley.edu/results.php?userid=111111
GUI URL:
   name: Computers
   description: View a list of the computers on which you are running SETI@Home
   URL: http://setiathome.berkeley.edu/hosts_user.php?userid=111111
GUI URL:
   name: Team
   description: View information about your team: neoX Group
   URL: http://setiathome.berkeley.edu/team_display.php?teamid=22222
GUI URL:
   name: Donate
   description: Donate to SETI@home
   URL: http://setiathome.berkeley.edu/sah_donate.php
   jobs succeeded: 16
   jobs failed: 0
   elapsed time: 107328.542101
   cross-project ID: 33333333333333333333333333333333

======== Tasks ========
1) -----------
   name: blc34_2bit_guppi_58406_27281_HIP20917_0104.20977.818.21.44.184.vlar_1
   WU name: blc34_2bit_guppi_58406_27281_HIP20917_0104.20977.818.21.44.184.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4658.869936
   CPU time at last checkpoint: 1902.641000
   current CPU time: 1949.207000
   fraction done: 0.202014
   swap size: 58 MB
   working set size: 56 MB
2) -----------
   name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.250.vlar_1
   WU name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.250.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4586.517845
   CPU time at last checkpoint: 1903.475000
   current CPU time: 1909.324000
   fraction done: 0.214406
   swap size: 58 MB
   working set size: 56 MB
3) -----------
   name: blc34_2bit_guppi_58406_27281_HIP20917_0104.20977.818.21.44.149.vlar_0
   WU name: blc34_2bit_guppi_58406_27281_HIP20917_0104.20977.818.21.44.149.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4643.434099
   CPU time at last checkpoint: 1902.425000
   current CPU time: 1904.189000
   fraction done: 0.204658
   swap size: 58 MB
   working set size: 56 MB
4) -----------
   name: blc34_2bit_guppi_58406_26949_HIP20491_0103.21476.0.21.44.21.vlar_1
   WU name: blc34_2bit_guppi_58406_26949_HIP20491_0103.21476.0.21.44.21.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4636.707813
   CPU time at last checkpoint: 1845.896000
   current CPU time: 1862.998000
   fraction done: 0.205810
   swap size: 54 MB
   working set size: 52 MB
5) -----------
   name: blc34_2bit_guppi_58406_28965_HIP20350_0109.21465.0.22.45.59.vlar_1
   WU name: blc34_2bit_guppi_58406_28965_HIP20350_0109.21465.0.22.45.59.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4665.477705
   CPU time at last checkpoint: 1781.304000
   current CPU time: 1805.969000
   fraction done: 0.200882
   swap size: 58 MB
   working set size: 56 MB
6) -----------
   name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.210.vlar_1
   WU name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.210.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4675.696451
   CPU time at last checkpoint: 1780.113000
   current CPU time: 1784.886000
   fraction done: 0.199132
   swap size: 58 MB
   working set size: 56 MB
7) -----------
   name: blc34_2bit_guppi_58406_28965_HIP20350_0109.21465.0.22.45.101.vlar_1
   WU name: blc34_2bit_guppi_58406_28965_HIP20350_0109.21465.0.22.45.101.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4705.804477
   CPU time at last checkpoint: 1711.990000
   current CPU time: 1768.862000
   fraction done: 0.193975
   swap size: 54 MB
   working set size: 52 MB
8) -----------
   name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.254.vlar_1
   WU name: blc34_2bit_guppi_58406_28625_HIP21029_0108.20913.818.21.44.254.vlar
   project URL: http://setiathome.berkeley.edu/
   received: Tue Apr  2 13:43:18 2019
   report deadline: Sat May 25 18:42:59 2019
   ready to report: no
   state: downloaded
   scheduler state: scheduled
   active_task_state: EXECUTING
   app version num: 800
   resources: 1 CPU
   estimated CPU time remaining: 4928.870679
   CPU time at last checkpoint: 1422.330000
   current CPU time: 1466.627000
   fraction done: 0.155767
   swap size: 54 MB
   working set size: 52 MB

boinccmd – the management tool for the command line

Here are the options you can use in version 7.14.2:

[myuser@compute1 ~]# boinccmd --help

usage: boinccmd [--host hostname] [--passwd passwd] [--unix_domain] command

default hostname: localhost
default password: contents of gui_rpc_auth.cfg
Commands:
 --acct_mgr attach URL name passwd  attach to account manager
 --acct_mgr info                    show current account manager info
 --acct_mgr sync                    synchronize with acct mgr
 --acct_mgr detach                  detach from acct mgr
 --client_version                   show client version
 --create_account URL email passwd name
 --file_transfer URL filename op    file transfer operation
   op = retry | abort
 --get_app_config URL               show app config for given project
 --get_cc_status
 --get_daily_xfer_history           show network traffic history
 --get_disk_usage                   show disk usage
 --get_file_transfers               show file transfers
 --get_host_info
 --get_message_count                show largest message seqno
 --get_messages [ seqno ]           show messages > seqno
 --get_notices [ seqno ]            show notices > seqno
 --get_project_config URL
 --get_project_status               show status of all attached projects
 --get_proxy_settings
 --get_simple_gui_info              show status of projects and active tasks
 --get_state                        show entire state
 --get_tasks                        show tasks
 --get_old_tasks                    show reported tasks from last 1 hour
 --join_acct_mgr URL name passwd    same as --acct_mgr attach
 --lookup_account URL email passwd
 --network_available                retry deferred network communication
 --project URL op                   project operation
   op = reset | detach | update | suspend | resume | nomorework | allowmorework | detach_when_done | dont_detach_when_done
 --project_attach URL auth          attach to project
 --quit                             tell client to exit
 --quit_acct_mgr                    same as --acct_mgr detach
 --read_cc_config
 --read_global_prefs_override
 --run_benchmarks
 --set_gpu_mode mode duration       set GPU run mode for given duration
   mode = always | auto | never
 --set_host_info product_name
 --set_network_mode mode duration   set network mode for given duration
   mode = always | auto | never
 --set_proxy_settings
 --set_run_mode mode duration       set run mode for given duration
   mode = always | auto | never
 --task url task_name op            task operation
   op = suspend | resume | abort

More clients in EPEL repository

[myuser@compute1 ~]# yum search boinc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.checkdomain.de
 * epel: mirror.wiuwiu.de
 * extras: mirror.checkdomain.de
 * updates: mirror.checkdomain.de
============================================================================ N/S matched: boinc ============================================================================
boinc-client.x86_64 : The BOINC client
boinc-client-devel.x86_64 : Development files for boinc-client
boinc-client-doc.noarch : Documentation files for boinc-client
boinc-client-static.x86_64 : Static libraries for boinc-client
boinc-manager.x86_64 : GUI to control and monitor boinc-client

  Name and summary matches only, use "search all" for everything.