Bug#815214: boinc-client: boinc client not updating log files

Preston Maness aspensmonster at riseup.net
Sat Feb 20 07:20:51 UTC 2016

Hash: SHA512

Howdy everyone,

Since boinc-client is now handled by the systemd service file, systemd
is determining where stdout and stderr go. You can run "journalctl -u
boinc-client.service" to get the logs, and if systemd has been set up
to also dump to syslog, the logs should be in /var/log/syslog as well
(I don't know if Debian defaults to this, or if I had set systemd to
dump logs there forever ago and have just forgotten about it).

Looking at the source code, it looks like there isn't an option for
cc_config.xml to specify where to put the logs. Originally, the init
script was utilized to appropriately redirect stdout and stderr as
needed with the LOGFILE and ERRORLOG environment variables
respectively, which ultimately were fed into the final command that
started the boinc-client. As well, there is also a "--redirectio" flag
that the boinc-client binary itself recognizes, which will redirect
stdout and stderr to files in the BOINCDIR environment variable instead.

Taking a look at the environment variables for my running boinc-client
at the moment, these are obviously not present:

# cat /proc/$(pidof boinc)/environ

(I'm not sure what LOGNAME is doing there, but I'm ignoring it)

Presumably, we should still be able to redirect the output as we
desire by modifying the boinc-client.service file's "ExecStart"
command. Looks like we're certainly not the only ones to run into this:


So something like:

ExecStart=/bin/sh -c '/usr/bin/boinc --dir /var/lib/boinc-client
> /var/log/boinc.log 2>/var/log/boincerr.log'

or whatever else is desired should work.


I changed my unit file's ExecStart to look like that, reloaded the
unit files via "systemctl daemon-reload", restarted boinc via
"systemctl restart boinc", and then the log files were written to again.

Preston Maness

P.S. - With respect to the other bug 813728 where the log has a bunch
of "No protocol specified" messages, I'm still thinking about how to
handle that one. The xorg-server is ultimately responsible for the
messages getting written. I'll fiddle with the freopen idea and see if
anything obvious breaks. Though honestly, I'm more inclined to just
leave things as-is. It's easy enough to rotate logs and grep out any
lines you don't want. Incidentally, with the change to the ExecStart
line, the "No Protocol Specified" lines get tossed into
/var/log/boincerr.log so they're not polluting the main
/var/log/boinc.log file. So that's nice. Honestly, that's probably
going to be my answer to that bug.

On 02/20/2016 12:50 AM, mark wrote:
> Package: boinc-client Version: 7.6.25+dfsg-1 Severity: important
> Dear Maintainer,
> As per email discussions with Gianfranco the boinc-client no longer
> seems to be updating its log files. This first occured on a number
> of Raspberry Pi's running the Stretch release around October 2015.
> This seems to have made its way into the amd64 build around January
> 2016.
> To try and narrow down the issue I have done the following:
> I have wiped the machine, downloaded Jessie 8.3 netinst(amd64) and
>  installed it. Removed x11-*. Sure its the old one and boinc-client
>  7.4.23 works as expected. Log files are in /var/lib/boinc-client.
>  Nothing in /var/log.
> Changed sources-list to point to Stretch and did a dist-upgrade 
> which along with everything else updated boinc to 7.6.25. After 
> install log files in /var/lib/boinc-client are no longer updated. 
> There are two log files in /var/log now, both zero bytes.
> Things the Rpi and amd64 have in common is x11-* was removed 
> (however x11-common gets installed by the dist-upgrade). Stretch 
> has GCC 5 whereas Jessie is still on GCC 4.9. I also have two 
> Parallella that use Gianfranco's Ubuntu ppa and they work as 
> expected (Ubuntu Trusty). The Parallella's also have x11-* 
> removed.
> * What led up to the situation? dist-upgrade to Stretch
> * What exactly did you do (or not do) that was effective (or 
> ineffective)? clean install Jessie followed by dist-upgrade to 
> Stretch
> * What was the outcome of this action? Log files no longer getting
>  updated
> * What outcome did you expect instead? Log files to work as before
> -- Package-specific info: -- Contents of
> /etc/default/boinc-client: # This file is
> /etc/default/boinc-client, it is a configuration file for the #
> /etc/init.d/boinc-client init script.
> # Set this to 1 to enable and to 0 to disable the init script. 
> # Set this to 1 to enable advanced scheduling of the BOINC core 
> client and # all its sub-processes (reduces the impact of BOINC on
>  the system's # performance). SCHEDULE="1"
> # The BOINC core client will be started with the permissions of 
> this user. BOINC_USER="boinc"
> # This is the data directory of the BOINC core client. 
> BOINC_DIR="/var/lib/boinc-client"
> # This is the location of the BOINC core client, that the init 
> script uses. # If you do not want to use the client program 
> provided by the boinc-client # package, you can specify here an 
> alternative client program. #BOINC_CLIENT="/usr/local/bin/boinc" 
> BOINC_CLIENT="/usr/bin/boinc"
> # Here you can specify additional options to pass to the BOINC core
> client. # Type 'boinc --help' or 'man boinc' for a full summary of
> allowed options. #BOINC_OPTS="--allow_remote_gui_rpc" 
> # Scheduling options
> # Set SCHEDULE="0" if prefering to run with upstream default 
> priority # settings.
> # Nice levels. When systems are truly busy, e.g. because of too 
> many active # scientific applications started by the boinc client,
>  there is a chance for # the boinc client not to be granted 
> sufficient opportunity to check for # scientific applications to be
> alive and make the (wrong) decision to # terminate the scientific
> app. This is particularly an issue with many # apps started in
> parallel on modern multi-core systems and extra overheads # for the
> download and uploads of files with the project servers. Another #
> concern is the latency for scientific applications to communicate
> with the # graphics card, which should be low. All such values
> should be set and # controled from within the BOINC client. The
> Debian init script also sets # extra constrains via chrt on real
> time performance and via ionice on # I/O performance, which is
> beyond the regular BOINC client. It then was # too easy to use that
> code to also constrain minimal nice levels. We still # think about
> how to best distinguish GPU applications from regular apps.
> #BOINC_NICE_APP_GPU=5        # not yet used
> # ionice classes. See manpage of ionice (1) in the util-linux 
> package. BOINC_IONICE_CLIENT=3        # idle 
> #BOINC_IONICE_APP_DEFAULT=3  # idle, not yet used 
> #BOINC_IONICE_APP_GPU=2      # best effort, not yet used
> -- System Information: Debian Release: stretch/sid APT prefers 
> testing APT policy: (500, 'testing') Architecture: amd64 (x86_64)
> Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: 
> LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: 
> /bin/sh linked to /bin/dash Init: systemd (via 
> /run/systemd/system)
> Versions of packages boinc-client depends on: ii  adduser 
> 3.113+nmu3 ii  ca-certificates        20160104 ii  debconf 
> [debconf-2.0]  1.5.58 ii  init-system-helpers    1.24 ii libboinc7
>  7.6.25+dfsg-1 ii  libc6                  2.21-8 ii libcurl3 
> 7.47.0-1 ii  libgcc1                1:5.3.1-8 ii libstdc++6 5.3.1-8
> ii  libx11-6               2:1.6.3-1 ii libxss1 1:1.2.2-1 pn
> python:any             <none> ii  zlib1g 1:1.2.8.dfsg-2+b1
> boinc-client recommends no packages.
> Versions of packages boinc-client suggests: pn  boinc-client-fglrx
>  <none> pn  boinc-client-nvidia-cuda  <none> pn boinc-client-opencl
>  <none> pn  boinc-manager             <none> pn x11-xserver-utils 
> <none>
> -- Configuration Files: /etc/boinc-client/gui_rpc_auth.cfg [Errno 
> 13] Permission denied: u'/etc/boinc-client/gui_rpc_auth.cfg' 
> /etc/boinc-client/remote_hosts.cfg changed [not included]
> -- debconf information: boinc-client/remove_boinc_dir: true



More information about the pkg-boinc-devel mailing list