None for over 5 weeks!

Lucky you. Do you have a secret?

Jean-David,
since it is a bash script, the ending should be .sh in order to keep system consistent with the applicable conventions.
Additionally, chmod +x shall be applied to the script file.
Cheers,
Yves

Asking for work often is only half the battle. The other half is ensuring that BOINC always thinks that you need work. You don't want to be the BOINC version of the kid asking every 30 seconds "are we there yet". Yes, using crontab on linux and the task scheduler on Windows to update the project regularly are necessary, BOINC will wait increasingly longer to ask for work if BOINC thinks you don't need any when you do ask. On the flip side, WCG will ignore requests if they are less than two minutes since the last request. If you ask too often, you can end up with a long string of requests that are ignored because of that and actually end up waiting longer to actually get new work. I do not recommend using crontab/scheduler to submit a project update request any more often than every five minutes. You also need to utilize the project limits in your device profiles in conjunction with your queue size to ensure that BOINC thinks you need new work each time you submit a project update request. That can be challenging depending on what projects you are crunching and how fast wu's from each of those projects take to complete on your machines. With the project limits in a device profile, 64 wu is the biggest limit other than unlimited. Using unlimited for a project that has wu's readily available effectively dooms any attempt to get any wu from limited volume projects like HSTB. Also, you have to balance that with maintaining a big enough work queue that your machines don't run out of work during any outage (it's the unplanned ones that are the main concern). So, for the projects you are crunching with readily available work, set their project limits so that you get enough work to keep your desired work queue size full or as close to that as possible. For projects like HSTB, set the project limit to unlimited. Finally, set the work queue size in the device profile to something that is larger than your volume from well supplied projects. Keep in mind as well what kind of deadline each project uses,

For example, the longest unplanned outage WCG has ever had was between 2-3 days. So, if you maintain a work queue of 3 days, your machines should stay busy crunching during any outage (planned or unplanned) at WCG and returned your backlog of completed work when the outage ends. If you have MCM, OPN and HSTB selected in your device profile and MCM wu's average 2 hours each to complete and OPN average 8 hours each and you want to split your runtime on the two equally, you would want to set the project limit for MCM to 18 and OPN to 5 for 36 and 40 hours of runtime each and just over the 72 hour (3 day) work queue size you really want. HSTB would be set to unlimited. Set the work queue size in the device profile to 4-5 days. Combined with your use of crontab/scheduler to submit regular project update requests, you will maintain your 3 day work queue of MCM and OPN work. However, because of the project limits you have set, you won't get any more than that even though you actually have your work queue set to 4-5 days. That way, each update request will be seen as you need more work but you have maxed MCM and OPN work so any work beyond that that is sent will be HSTB if there is any HSTB work available when that request is processed.

Given that most projects usually have a 5-7 day deadline, you definitely want to avoid having too much work in queue, Don't set your queue size higher than 5 days (probably 4.5 max actually). You do want to be careful. If you change projects, you have to do some planning beforehand so that you set the project limits accurately. If you have multiple machines that vary in their performance, it can get complicated figuring out the correct project limits (try figuring that for your machines in aggregate perhaps). Start out playing it conservative and do small upward tweaks.

I currently have 51 cores crunching and 78 HSTB wu in queue across those cores.