For those who understand BOINC behind the scenes a bit, I have a question. Why is there a boinc-client init script /etc/init.d/boinc-client as well as a systemd unit file /lib/systemd/system/boinc-client.service? Is there any interaction between the two or is it just so that BOINC can run on systemd and non-systemd Linux installations?

My question stems from the following. I use WSL2 Ubuntu to run Linux BOINC projects and up to recently WSL2 was init.d. Recently, on the latest Windows 10 and 11 updates, WSL2 became Generally Available and systemd became an option one can turn on. I updated and tried turning on systemd but BOINC didn't behave as expected. The config file /etc/default/boinc-client didn't seem to have been read. I did some learning about systemd and have a bit better understanding of things now but would like an answer to my question to make sure my suspicion is right.

BOINC itself provided the script to run under init.d until three or four years ago.

A volunteer developer suggested, and provided a script for, operation under systemd. That is now the normal mode for Linux distributions.

Normally, a systemd implementation runs in a sandbox with very limited access to and from the host's other users. It runs under user boinc, a member of group boinc. These settings are created by the distro repository installation tools. You don't say exactly which config file can't be read, and who it can't be read by, but the usual problem is that the operator's login account can't read files assigned to group boinc. Add your user name to that group, and check that the membership is active - the easiest brute force method is to reboot the machine.

I did mention the config file. it's called boinc-client and it's located in /etc/default/. It's a configuration file for the /etc/init.d/boinc-client init script. That's the script that I was asking about. When starting BOINC in standard WSL2 (i.e. systemd not enabled), that's the start up script that one would run directly or with service boinc-client start command. It reads the config file mentioned for any adjustments the user wants to make.

With systemd enabled, trying to start BOINC as above, a message appears that BOINC was started with the unit file boinc-client.service that I mentioned. Both the init.d script and systemd unit file point to /usr/bin/boinc, which I assume is the executable. It appears that the init.d script is used to start BOINC in non systemd installation and the boinc-client.service unit file is used to start BOINC in systemd installations. It seems also that to modify start up configuration in systemd, another method is used and the config file mentioned is not read. I was hoping to get some confirmation or explanation on this. Is this how it works?

In my Linux Mint installations (Ubuntu-like under the skin), /var/lib/boinc-client is the primary working folder (directory), containing data only.

The adjacent 'boinc' is a re-direction to boinc-client, for backwards compatibility.

The executable programs live in /usr/bin, where usr/bin/boinc is indeed an executable file.

The user-editable configuration files live in the folder /etc/boinc-client, where the primary file is called cc_config.xml - there's also a re-direction link in /var/lib/boinc-client, called cc_config.xml and pointing to the editable data in /etc/boinc-client

I'm using Ubuntu 22.04. How did you install BOINC?

In addition to what you listed, I have the start up config file (not .xml) /etc/default/boinc-client, the init script /etc/init.d/boinc-client, and the systemd unit file /lib/systemd/system/boinc-client.service. Do you not have those? It'd seem strange as those are part of standard installation, at least in Ubuntu, which can be confirmed here https://packages.ubuntu.com/jammy/amd64/boinc-client/filelist. I can't find a similar repository info for Mint to see a list of files but if it's Ubuntu based I'd seem odd that BOINC for Mint wouldn't have them.

Ah. I see where we're getting at cross-purposes. You're concentrating on the process of installation - the scripts and configurations that determine what goes where, and what gets changed during installation.

I've been concentrating on the result of installation - the 'payload', if you like: how to control and run BOINC after it's been installed.

In my case, boinc v7.18.1 was installed from the Linux Mint 21 repositories, which some people have had difficulties with. Mine just installed and ran without a flaw, although I've upgraded the binaries manually to v7.20.5 since then. I've never even needed to look at what happened during installation.

Let me have another cup of coffee and go and re-read your original question, and we can re-start the conversation from there.

My question stems from the following. I use WSL2 Ubuntu to run Linux BOINC projects and up to recently WSL2 was init.d. Recently, on the latest Windows 10 and 11 updates, WSL2 became Generally Available and systemd became an option one can turn on. I updated and tried turning on systemd but BOINC didn't behave as expected. The config file /etc/default/boinc-client didn't seem to have been read. I did some learning about systemd and have a bit better understanding of things now but would like an answer to my question to make sure my suspicion is right.

The file in /etc/default/boinc-client is part of init.d and completely separate from the files used by systemd which uses config files not a shell script like init.d.

You can find the systemd 'service' default files in /lib/systemd/system/boinc-client.service and also in /etc/systemd/system/boinc-client.service.d for user 'override' files for settings that you alter.

For the override file either use the systemctl edit command or just create the file yourself and then restart the service. So for example, on one of my machines I split boinc into two services, one for CPDN and one for everything else. That means I have the following files:

$ ls -l /lib/systemd/system/boinc*
-rw-r--r-- 1 root root 1111 Oct 23 17:54 /lib/systemd/system/boinc-client-cpdn.service
-rw-r--r-- 1 root root 1111 Jan 30  2022 /lib/systemd/system/boinc-client.service

where both these files are identical and as they were installed. Then I have my customizations in /etc/systemd/system/:

$ ls -l /etc/systemd/system/boinc*
/etc/systemd/system/boinc-client-cpdn.service.d:
-rw-r--r-- 1 root root 690 Oct 23 18:20 override.conf

/etc/systemd/system/boinc-client.service.d:
-rw-r--r-- 1 root root 500 Oct 23 13:47 override.conf

where these override files look like:

$ cat boinc-client.service.d/*
[Service]
#  Note multiple ExecStart lines are allowed, so default in /lib/systemd/system/boinc-client.service
#  must be cleared first
# /work is the SSD

WorkingDirectory=/work/boinc-client
ReadWritePaths=-/work/boinc-client -/etc/boinc-client
ExecStart=
ExecStart=/usr/bin/boinc --allow_multiple_clients --allow_remote_gui_rpc --dir /work/boinc-client

# Override ProtectSystem to allow VBox to run, othewise it can't access /tmp (see https://github.com/BOINC/boinc/issues/3355)
ProtectSystem=full

$ cat boinc-client-cpdn.service.d/*
[Service]
#  Note multiple ExecStart lines are allowed, so default in /lib/systemd/system/boinc-client.service
#  must be cleared first
# /work is the SSD

# !!! CPDN version !!!

WorkingDirectory=/work/boinc-client-cpdn 
ReadWritePaths=-/work/boinc-client-cpdn -/etc/boinc-client 
ExecStart= 
ExecStart=/usr/bin/boinc --allow_multiple_clients --allow_remote_gui_rpc --gui_rpc_port 31417 --dir /work/boinc-client-cpdn
ExecStop=/usr/bin/boinccmd --host 127.0.0.1:31417 --quit
ExecReload=/usr/bin/boinccmd --host 127.0.0.1:31417 --read_cc_config

# Override ProtectSystem to allow VBox to run, othewise it can't access /tmp (see https://github.com/BOINC/boinc/issues/3355)
ProtectSystem=full

I also have an alias for the boincmgr command to use the different port for the CPDN boinc-client.

For WSL2 of course, it's not a normal boot service so on my WSL I start the boinc-client by init.d when my account starts up (so it's running as me not root). I have not yet tried systemctl on WSL.

Hope that's useful.

Thanks Glenn. Can you answer a quick rider to that?

To my mind, an installation requires:

a) a container [archive, tarball, zip - format doesn't matter] holding all the applications, scripts, data files, related images etc.
b) a signpost saying "start with this one".

So far, I've been searching for, and failing to find, any sign of the raw container files for Linux software packages - either repos or PPAs. If I could find the raw container, and open it, that would give me a much clearer idea of which files belong with 'this' installation, and which files belong to 'that' installation - init.d and systemd, in this case.

Any ideas?

Thanks Glenn. Can you answer a quick rider to that?
So far, I've been searching for, and failing to find, any sign of the raw container files for Linux software packages - either repos or PPAs. If I could find the raw container, and open it, that would give me a much clearer idea of which files belong with 'this' installation, and which files belong to 'that' installation - init.d and systemd, in this case.

I may not exactly understand your question, but the init.d & systemctl startup files & configurations are bundled together in the same boinc client linux 'package' (aka 'container').

The packages in the repo, for Linux Mint for example can be found here: http://packages.linuxmint.com/. If you click into one of these releases, you can then click on the 'Source dir' link to see the list of packages. I suspect you already know this which is why I am not sure I've answered the question.

Well, doing local domestic support, I've often found myself resorting to this analogy:

Teaching your computer to do something new is like coming home from holiday.

First, your taxi driver brings you home from the airport, and drops your suitcase in the hallway. (that's downloading)
Then you unpack the suitcase: dirty clothes to the washing machine, guidebooks to the bookshelf, souvenirs to the mantelpiece, toothbrush to the bathroom, half-eaten sandwich to the trash, and so on. (that's installing)

On that model - where's the hallway (folder), and what's the suitcase called (file)?

Thank you Glenn. That's what conclusions I've been coming to as well but wanted input from someone more knowledgeable. This is my first foray into systemd. The override files seem to function like the config files in /etc/default/. It seems like there's a directive called Environment= that one can use to add flags to the ExecStart= values. The main thing I need is for WSL2 client to start with a different port so that I can view and control it from the Windows manager. I'll try to read up some more and try it on WSL2 this week. One of my motivations to try WSL2 with systemd is hopefully to get LHC to run better. The initial attempts running LHC with systemd enabled produced very strange errors: cvmfs-config probe checks out ok when ran as a separate command but fails when ran in the wrapper at task start up. I wonder if systemd WSL2 has its additional quirks like it does in the standard init.d mode.

By the way, is this your post on the topic on BOINC forum back in August: https://boinc.berkeley.edu/forum_thread.php?id=14755?

Richard, I know you're looking for something more technical, but one thing I like about Ubuntu package repository site is that there's a lot of info there, including an installation directory, i.e. a list of all files and where they go.

By the way, is this your post on the topic on BOINC forum back in August: https://boinc.berkeley.edu/forum_thread.php?id=14755?

Richard, I know you're looking for something more technical, but one thing I like about Ubuntu package repository site is that there's a lot of info there, including an installation directory, i.e. a list of all files and where they go.

And thank you, Andrey. Those two both give me a clear signpost.

I have now downloaded a file called 'boinc-client_7.18.1+dfsg-4_amd64.deb', and I can see that it contains two subsidiary files, 'control.tar.zst' and 'data.tar.zst': I think that answers my 'hallway and suitcase' question. I haven't got into the suitcase yet, but I'm just playing around on a Windows machine at the moment. It gives me the direction of travel for the next stage.

I would expect that the Ubuntu archive is very similar to the one that Mint might supply. I also have a Mint 20.3 machine, and I loaded that machine from Gianfranco Costamagna's PPA (https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/boinc). That has served me well over the years for test releases, but Mint 21 rejects the security model used by PPAs.

The BOINC message board post also gives me an idea for the machine which is running out of disk space. I think my local SSD supplier might be hearing from me very soon!