Sigh...I saw 11,000+ tasks out for processing earlier. And I didn't get a one of them. My queues are clogged up with WCG, and the occasional Einstein. I say occasional because (excuse the formatting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8991 boinc 39 19 2407100 2.294g 9428 R 92.55 19.78 9,47 einstein_+

Doesn't allow for many of them.

---

Hi Bill,
Maybe you can catch some of those Rosetta Work Units with a Batch file
Like this - Upd-Rosetta.bat
@echo off
cd /d c:Program FilesBOINC
:loop
cls
echo "boinccmd.exe --project https://boinc.bakerlab.org/rosetta/ update"
boinccmd.exe --project https://boinc.bakerlab.org/rosetta/ update

TIMEOUT /T 600
goto loop

Of course you would need to leave a terminal window open for that

I tried the Windows Task Scheduler Loop - but the Win 10 task scheduler doesn't
seem very reliable. I can't seem to scale to 5 minute intervals very well.

Regards,
Ian

---

Hi Bill,
Maybe you can catch some of those Rosetta Work Units with a Batch file
Like this - Upd-Rosetta.bat
@echo off
cd /d c:Program FilesBOINC
:loop
cls
echo "boinccmd.exe --project https://boinc.bakerlab.org/rosetta/ update"
boinccmd.exe --project https://boinc.bakerlab.org/rosetta/ update

TIMEOUT /T 600
goto loop

Of course you would need to leave a terminal window open for that

I tried the Windows Task Scheduler Loop - but the Win 10 task scheduler doesn't
seem very reliable. I can't seem to scale to 5 minute intervals very well.

Regards,
Ian

Thanks a lot! Just got it set up on 3 computers, hopefully I'll catch something sometimes... About 2 hours ago I only got tasks on 2 mobile phones despite rushing to press update on several computers.

---

Thanks Ian. I run openSUSE. This is my take on your routine though:
bill@opihi:~> cat bin/mowerk
#
# This doohickie will attempt to get work for the main
# projects that I'm supporting.
#
# set -x
#
# How many days worth of work...
# su and cd to /var/lib/boinc
# then vi global_prefs_overide
# and modifiy thusly
# <work_buf_min_days>0.000000</work_buf_min_days>
# <work_buf_additional_days>0.260000</work_buf_additional_days>
# Then
# systemctl restart boinc-client
#
cd
#
# Some interesting things to beat projects up with.
#
#boinccmd --project https://einstein.phys.uwm.edu allowmorework
#boinccmd --project https://einstein.phys.uwm.edu nomorework
#
# Just touch the projects to gather the statistics.
# In alphabetical order no less. Well it was, now it's in my
# simple choice of project complettion and not prodding those
# other two...
#
# boinccmd --project https://denis.usj.es/denisathome update
sleep 30s
boinccmd --project https://boinc.bakerlab.org/rosetta update
sleep 30s
# boinccmd --project https://einstein.phys.uwm.edu update
sleep 1m
boinccmd --project https://www.worldcommunitygrid.org update
sleep 1m
#
# OK, is this a one time thing, or what.
# If not, rapidly update at a 5 minute interval.
# Yeah my math is lousy...it doesn't calculate correctly, but
# you know what? I don't care enough to fix it.
#
if [ "$1" > "" ] ;
then
Reps=`expr $1 - 1`
while [ $Reps -gt 0 ] ; do
Ttl=`echo "$Reps * 5" | bc`
echo "It's" `date '+%T'` "- on repetition" $Reps "- ttl is $Ttl minutes"
boinccmd --project https://denis.usj.es/denisathome update
boinccmd --project https://boinc.bakerlab.org/rosetta update
sleep 10s
# boinccmd --project https://einstein.phys.uwm.edu update
boinccmd --project https://www.worldcommunitygrid.org update
#
Reps=`expr $Reps - 1`
if [ $Reps = 0 ] ;
then
echo "Lightspeed Thumbtwiddling...All Done!"
exit
fi
sleep 5m
done
else
exit
fi

---

On a linux box ( - mine is Linux Mint 22.3), an easy way to poll for new rosetta tasks is using
a crontab entry - I use this
crontab -e
then add -

# Update BOINC's Rosetta Project every 2 Minutes to catch stray WUs
*/2 * * * * /usr/bin/boinccmd --project https://boinc.bakerlab.org/rosetta/ update

I see you're trying also trying the Denis project - I don't think I've seen any activity since
June 2025 on this one. Einstein always seems to have Work Units available though, as
does WCG when it's up.
I try to crunch on Cancer oriented research, as my wife, and mom both died of cancer,
and I'm also struggling with leukemia. I'm glad research like WCG/Folding@Home are still
going strong. FAH even seems to be looking at the KRAS protein involved in a lot of cancers.
I hope us crunchers can really help those researchers!
Anyway try a simple cron job for updating - no need for scripts on linux!
Ian

---

pour windows et tous les projets boinc

@echo off
pushd "C:Program FilesBOINC"

:loop
echo [%date% %time%] Debut de la mise a jour automatique...

:: On recupere directement la liste des URLs propres
for /f "usebackq tokens=*" %%a in (`boinccmd.exe --get_project_urls`) do (
echo Mise a jour en cours : %%a
boinccmd.exe --project "%%a" update
)

echo.
echo [%date% %time%] Fin de session. Prochaine verification dans 30 min.
timeout /t 1800 /nobreak >nul
goto loop


pour windows et un projet boinc

@echo off
:loop
"C:Program FilesBOINCboinccmd.exe" --project https://gpugrid.net/gpugrid/ update
timeout /t 900 /nobreak >nul
goto loop


instruction a mettre dans un fichier.bat et a lancer en mode administrateur

---

@Pascal - looks good though time period of 1800 may miss some work units - but in my poor French - tres bon!
I also see that the task scheduler is actually working on my old Win 10 laptop - I was wrong to maligh it!
It's running at 5 minute intervals now.
Here's my Event Log -
2/13/2026 2:57:22 AM | Rosetta@home | Scheduler request completed
2/13/2026 2:57:22 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:02:20 AM | Rosetta@home | update requested by user
2/13/2026 3:02:20 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:02:20 AM | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)
2/13/2026 3:02:22 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:02:22 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:07:19 AM | Rosetta@home | update requested by user
2/13/2026 3:07:20 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:07:20 AM | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)
2/13/2026 3:07:21 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:07:21 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:12:19 AM | Rosetta@home | update requested by user
2/13/2026 3:12:24 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:12:24 AM | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)
2/13/2026 3:12:25 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:12:25 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:17:19 AM | Rosetta@home | update requested by user
2/13/2026 3:17:23 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:17:23 AM | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)
2/13/2026 3:17:24 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:17:24 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:18:04 AM | | Resuming GPU computation
2/13/2026 3:20:49 AM | | Suspending GPU computation - computer is in use
2/13/2026 3:22:19 AM | Rosetta@home | update requested by user
2/13/2026 3:22:22 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:22:22 AM | Rosetta@home | Not requesting tasks: don't need (CPU: ; Intel GPU: no applications)
2/13/2026 3:22:24 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:22:24 AM | Rosetta@home | Project requested delay of 31 seconds
2/13/2026 3:27:19 AM | Rosetta@home | update requested by user
2/13/2026 3:27:21 AM | Rosetta@home | Sending scheduler request: Requested by user.
2/13/2026 3:27:21 AM | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)
2/13/2026 3:27:22 AM | Rosetta@home | Scheduler request completed
2/13/2026 3:27:22 AM | Rosetta@home | Project requested delay of 31 seconds

The Task Scheduler seems to be an easier way to run Rosetta updates every 5 minutes as set and forget!
Ian

---

I run a background script on my main linux computer that polls my boinc computers in a random order using ssh, some are windows, some are linux. Only started this recently, I didn't realise how many others are doing the same. Uses a list file for the target computers that you can update on the fly. It took a while to get the windows ssh syntax working.

EDIT: tried to add code but the forum code tags aren't working properly and the escaped characters don't show.

---

https://boincot.uk

sous linux mint 22

watch -n 300 boinccmd --project https://boinc.bakerlab.org/rosetta/ update

watch -n 3600 'for url in $(boinccmd --get_project_status | grep "master URL" | awk "{print $3}"); do echo "→ $url"; boinccmd --project "$url" update; done'

a lancer dans terminal ou lanceur terminal

---

I went away and forgot to come back, until tonight
I don't think I missed anything at WCG that worked, except reduced deadlines from 7 to 3 or 4 days
The latest update teases us with possibilities, including stats export, which I'll believe when I see it

February 19, 2026
We are rolling out BOINC server release 1.6.1 in production, as we successfully re-based our BOINC server build onto recently released upstream v1.6.1 and cherry-picked changes from legacy and new WCG development, passing all tests and adding new ones for WCG-specific customizations. The scheduler, transitioner, and feeder will now run alongside the create_work daemons, Redpanda brokers, file_upload_handlers, and combined validator_assimilator daemons on the BOINC backend cluster and serve only the node local partition, handling only BOINC client requests routed to that server by the load balancer.
We are migrating the SQLite instances across the BOINC backend nodes to a Citus-Data v14.0 PostgreSQL database cluster, completing our transition to a horizontally scalable architecture for the BOINC backend via the Redpanda cluster, PostgreSQL database cluster, and our changes to enforce end-to-end data locality in workunit processing within individual partitions by changing signed URL generation to include buckets owned by a specific partition/node on the backend, and providing the load balancer a mapping of buckets to the correct backend node. While we have had bugs in multiple components as we made changes to the backend, all components now consistently apply the same hashing function to a given workunit ID to achieve correct routing, and as we loop the database and scheduler into this design we expect to finally be able to communicate the value of the new architecture in results as we restart ARP1, and finally rollout MAM1 and seek to backport the MAM1 application to the MCM1 project, for BOINC clients running on devices that can handle it. We will not close the path for less powerful devices to contribute, only add the path for more powerful devices to contribute more than they currently can.
MAM1 v7.0.8 for Linux and Windows, and ARP1 will release as soon as the BOINC server v1.6.1 and distributed PostgreSQL database cluster rollouts are complete, we will then also enable stats export. We will be able to gather the remaining backlog for validation from the postgres cluster more easily than the currently bogged down legacy BOINC database, and perform the final phase of validation backlog reconciliation.
Results page under My contribution, as correctly guessed in the forums, the botched rollout of the new results page was a direct attempt to reduce load on the BOINC database from the APIs now that result tables have grown so large, while attempting to preserve the ability of volunteers to inspect their results and confirm for themselves the validation state of their PV jails, which we have finally made progress on. After restoring basic functionality of the new server-side in-memory caching approach, we left several issues unresolved and proceeded to work on the above items. A fix is incoming to enable downloading all results instead of the 500 currently displayed, and to fix the conditions that cause the summary stats to show more results in the numerator than in the denominator, and to address the behaviour of filtering among others.
Fixed Apache mod-security rules blocking Team Challenge and Invite to Challenge functionality, and we suspect multiple other 403 forbidden issues to be related to the upgrades to the Apache webserver and HAProxy load balancer at the start of the transition. More fixes are incoming for the website, once we have completed the rollout of the final pieces of our new horizontally scalable architecture, removing the BOINC database as a single point of contention, and launching all remaining applications as described above.

---

An update I missed a few days ago

March 6, 2026
Upcoming Database Migration Will Require Taking BOINC Database Offline Between March 10th-11th - we have been testing the distributed Postgres architecture in our new staging environment. We intend to switch over to our Postgres build of the BOINC server v1.6.1 release next week, between March 10th-11th. The cutover will require a brief pause while we deploy the updated scheduler and feeder to each Postgres worker node, and rollout CDC via Kafka in production to match the staging deployment. With CDC, we will keep the legacy databases in sync with workunit state managed by the Postgres cluster.
CRUD operations from create_work and validator_assimilator daemons will be pipelined by a journaling process to keep workunit state eventually consistent in the legacy BOINC database, so that the current API layer and business logic will continue to work as usual. What we gain is the IOPS available to the BOINC database will scale to the number of servers we deploy in the Postgres cluster, and batch updates to the database will preserve data locality, completing the horizontally scalable design.
This should resolve the long-standing validation issues, high disk utilization for the current BOINC database, and enable us to return to strict homogenous redundancy classes for MCM1 workunits, solve the os_name and os_version buffer overflow and trunctation bug, and give us access to the new features implemented in the more recent BOINC releases, such as running containers as applications on the grid.
We are able to produce and run MCM1 and MAM1 workunits through this system in staging, and will launch ARP1 shortly after we confirm it delivers as expected and described above. We also should then be able to release a larger quantity of workunits than we were previously able to for ARP1 and accelerate the completion of the project.

---

March 6, 2026
Upcoming Database Migration Will Require Taking BOINC Database Offline Between March 10th-11th - we have been testing the distributed Postgres architecture in our new staging environment. We intend to switch over to our Postgres build of the BOINC server v1.6.1 release next week, between March 10th-11th. The cutover will require a brief pause while we deploy the updated scheduler and feeder to each Postgres worker node, and rollout CDC via Kafka in production to match the staging deployment. With CDC, we will keep the legacy databases in sync with workunit state managed by the Postgres cluster.

March 16, 2026
Data transfer from legacy MariaDB to Postgres is ongoing for the largest partitioned table in the BOINC database, the result table. All other tables were transferred successfully to the postgres cluster.
We tested every component in production, and we expect to bring the system back online for users at the load balancer as soon as the data transfer and final integrity check between the legacy and new database are complete.

---

March 23, 2026
Many issues identified and fixed after bringing the WCG backend online last week Thursday, March 19th, 2026 running the new Postgres-enabled BOINC v1.6.1 backend in production: We found multiple missing indexes in our Postgres schema that the small scale of our staging environment did not reveal as necessary. We also had to setup the Postgres extension pgbouncer to pool connections to on each Postgres worker node to pool the large number of connections, and address multiple oversights in our CDC pipeline that resulted in incorrectly decoding user prefs coming from MariaDB into Citus reference tables, and no stats updates for the first few update windows on the website since we came back online. The credit_flusher that gathers the global view of what results need their state updated in MariaDB from the Citus coordinator was omitting key columns from those updates. We also had to iterate on MariaDB binlog settings together with Kafka to get CDC working in prod. With the bottleneck load now spread across the IOPS available to 6 servers without requiring a full migration of the legacy BOINC database which is under 100% disk utilization for the first time at the new site while under production load, we are now going to be able to clear the validation backlog, launch and resume projects, fix the daily stats on the website, resume the stats dump, and fix the results page so that Volunteers can verify the state of their backlogs. A server status page has been implemented in our staging environment, we plan to push it to the live site this week or next.
We have one major issue with one of the six backend servers at the moment (3pm UTC); we have reached out to hosting for assistance: We were able to recover the Postgres cluster morning of March 23rd, 2026 (EST time) from the crash yesterday March 22nd, but this 1/6 postgres worker is behaving differently than the other partitions despite identical config and executables running on it. It has become unresponsive again, and we reached out to hosting about this in case it is hardware or cloud. We have blocked that server at the load balancer from receiving scheduler requests, so the download and reporting path should be functional for all requests now, but uploads mapped to that server will continue to display HTTP transient errors until we resolve the problem.

---