It's back up and running, the system didn't save the sleep 30 line, no clue why, unless it has to do with this system being pxe-boot.
Steps to fix the issue:
1. Stop all boinc projects and exit boinc manager with stop projects selected then systemctl stop boinc-client.
2. Navigate to the boinc folder, in my case /var/lib/boinc-client, and run boinc and let it run for a few minutes.
3. Ctrl+c the running instance of boinc after it starts crunching on projects.
4. Systemctl start boinc-client.
5. Start boinc manager and let it error out "disconnected local host" then exit out but leave projects running.
6. Start boinc manager again and watch the magic.
Not sure why these steps worked still not convinced this isn't a bug that hasn't been found due to this being a pxe-boot. I'm just glad it's fixed. Thanks everyone for your ideas...I might try said steps on my servers that have decent vid cards to see if they will crunch.
Unfortunately, that doesn't delay BOINC itself (which I was suggesting might be the culprit here). The <start_delay> only applies to project science apps: BOINC itself has to have started first in order to read the config file, and apply that delay to the next stage in the process.
Thanks for the clarification.
Keith Myers wrote:
In the BOINC .service file, edit it to add a delay so that the video drivers are fully initialized.
Insert this into the file:
[Service]
ExecStartPre=/bin/sleep 30
before the normal ExecStart call for boinc
Slick trick. I wasn't even aware of that service file. On my Ubuntu/Debian system the file path is:
/lib/systemd/system/boinc-client.service
Ideas are not fixed, nor should they be; we live in model-dependent reality.
In the BOINC .service file,
)
In the BOINC .service file, edit it to add a delay so that the video drivers are fully initialized.
Insert this into the file:
before the normal ExecStart call for boinc
It's back up and running, the
)
It's back up and running, the system didn't save the sleep 30 line, no clue why, unless it has to do with this system being pxe-boot.
Steps to fix the issue:
1. Stop all boinc projects and exit boinc manager with stop projects selected then systemctl stop boinc-client.
2. Navigate to the boinc folder, in my case /var/lib/boinc-client, and run boinc and let it run for a few minutes.
3. Ctrl+c the running instance of boinc after it starts crunching on projects.
4. Systemctl start boinc-client.
5. Start boinc manager and let it error out "disconnected local host" then exit out but leave projects running.
6. Start boinc manager again and watch the magic.
Not sure why these steps worked still not convinced this isn't a bug that hasn't been found due to this being a pxe-boot. I'm just glad it's fixed. Thanks everyone for your ideas...I might try said steps on my servers that have decent vid cards to see if they will crunch.
coprocs_info.xml:
<coprocs>
<coproc_intel_gpu>
<count>0</count>
<name>Intel(R) HD Graphics Skylake Desktop GT2</name>
<available_ram>4131389440.000000</available_ram>
<have_opencl>0</have_opencl>
<peak_flops>184000000000.000000</peak_flops>
<version>1.3</version>
</coproc_intel_gpu>
<ati_opencl>
<name>AMD OLAND (DRM 2.50.0, 4.19.0-16-amd64, LLVM 7.0.1)</name>
<vendor>AMD</vendor>
<vendor_id>4098</vendor_id>
<available>1</available>
<half_fp_config>6</half_fp_config>
<single_fp_config>6</single_fp_config>
<double_fp_config>63</double_fp_config>
<endian_little>1</endian_little>
<execution_capabilities>1</execution_capabilities>
<extensions>cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp64 cl_khr_fp16</extensions>
<global_mem_size>2147483648</global_mem_size>
<local_mem_size>32768</local_mem_size>
<max_clock_frequency>900</max_clock_frequency>
<max_compute_units>6</max_compute_units>
<nv_compute_capability_major>0</nv_compute_capability_major>
<nv_compute_capability_minor>0</nv_compute_capability_minor>
<amd_simd_per_compute_unit>0</amd_simd_per_compute_unit>
<amd_simd_width>0</amd_simd_width>
<amd_simd_instruction_width>0</amd_simd_instruction_width>
<opencl_platform_version>OpenCL 1.1 Mesa 18.3.6</opencl_platform_version>
<opencl_device_version>OpenCL 1.1 Mesa 18.3.6</opencl_device_version>
<opencl_driver_version>18.3.6</opencl_driver_version>
<device_num>0</device_num>
<peak_flops>432000000000.000000</peak_flops>
<opencl_available_ram>2147483648.000000</opencl_available_ram>
<opencl_device_index>0</opencl_device_index>
<warn_bad_cuda>0</warn_bad_cuda>
</ati_opencl>
<intel_gpu_opencl>
<name>Intel(R) HD Graphics Skylake Desktop GT2</name>
<vendor>Intel</vendor>
<vendor_id>32902</vendor_id>
<available>1</available>
<half_fp_config>6</half_fp_config>
<single_fp_config>6</single_fp_config>
<double_fp_config>0</double_fp_config>
<endian_little>1</endian_little>
<execution_capabilities>3</execution_capabilities>
<extensions>cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups cl_intel_subgroups_short cl_khr_gl_sharing cl_khr_fp16</extensions>
<global_mem_size>4131389440</global_mem_size>
<local_mem_size>65536</local_mem_size>
<max_clock_frequency>1000</max_clock_frequency>
<max_compute_units>23</max_compute_units>
<nv_compute_capability_major>0</nv_compute_capability_major>
<nv_compute_capability_minor>0</nv_compute_capability_minor>
<amd_simd_per_compute_unit>0</amd_simd_per_compute_unit>
<amd_simd_width>0</amd_simd_width>
<amd_simd_instruction_width>0</amd_simd_instruction_width>
<opencl_platform_version>OpenCL 2.0 beignet 1.3</opencl_platform_version>
<opencl_device_version>OpenCL 2.0 beignet 1.3</opencl_device_version>
<opencl_driver_version>1.3</opencl_driver_version>
<device_num>0</device_num>
<peak_flops>184000000000.000000</peak_flops>
<opencl_available_ram>4131389440.000000</opencl_available_ram>
<opencl_device_index>0</opencl_device_index>
<warn_bad_cuda>0</warn_bad_cuda>
</intel_gpu_opencl>
<warning>NVIDIA: libcuda.so: cannot open shared object file: No such file or directory</warning>
<warning>ATI: libaticalrt.so: cannot open shared object file: No such file or directory</warning>
</coprocs>
Good you got it working. My
)
Good you got it working. My own recipe is
systemctl stop boinc-client
systemctl disable boinc-client
Do whatever maintenance work is needed, reboot, etc.
Wait until system is fully stable and running
systemctl enable boinc-client
systemctl start boinc-client
I haven't tried the sleep 30 yet - maybe next time.
Richard Haselgrove
)
Thanks for the clarification.
Slick trick. I wasn't even aware of that service file. On my Ubuntu/Debian system the file path is:
/lib/systemd/system/boinc-client.service
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Quote: Slick trick. I wasn't
)
Mine is located at /etc/systemd/system/multi-user.target.wants/boinc-client.service on my RPi 3B+
Keith Myers wrote:Mine is
)
Ah, yes, on mine that path is a symbolic link to the file in /lib/systemd/system/. I'm getting quite an education today on Linux systems!
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Likely depends on the distro
)
Likely depends on the distro and how it handles services and the variabilities of systemd.
On mine, the service was just a standalone file in /etc/systemd/system/multi-user.target.wants/ and not a symlink.