LHC@home

This requires a BOINC client update once they publish a version without that bug.

OK, I will look out for it. Forewarned is forearmed.
That answers a long-standing question. Thanks.

Every 12th minute a problem is reported in StartdLog:

09/09/21 07:45:52 (pid:16121) CONFIGURATION PROBLEM: Failed to insert ClassAd attribute GLIDEIN_Resource_Slots = Iotokens,80,,type=main.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the STARTD ad.
09/09/21 07:45:52 (pid:16121) CONFIGURATION PROBLEM: Failed to insert ClassAd attribute STARTD_JOB_ATTRS = ,x509userproxysubject,x509UserProxyFQAN,x509UserProxyVOName,x509UserProxyEmail,x509UserProxyExpiration,MemoryUsage,ResidentSetSize,ProportionalSetSizeKb.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the STARTD ad.
09/09/21 07:45:52 (pid:16121) CONFIGURATION PROBLEM: Failed to insert ClassAd attribute STARTD_PARTITIONABLE_SLOT_ATTRS = MemoryUsage,ProportionalSetSizeKb.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the STARTD ad.
09/09/21 07:45:52 (pid:16121) slot1: CONFIGURATION PROBLEM: Failed to insert ClassAd attribute GLIDEIN_Resource_Slots = Iotokens,80,,type=main.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the slot1 ad.
09/09/21 07:45:52 (pid:16121) slot1: CONFIGURATION PROBLEM: Failed to insert ClassAd attribute STARTD_JOB_ATTRS = ,x509userproxysubject,x509UserProxyFQAN,x509UserProxyVOName,x509UserProxyEmail,x509UserProxyExpiration,MemoryUsage,ResidentSetSize,ProportionalSetSizeKb.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the slot1 ad.
09/09/21 07:45:52 (pid:16121) slot1: CONFIGURATION PROBLEM: Failed to insert ClassAd attribute STARTD_PARTITIONABLE_SLOT_ATTRS = MemoryUsage,ProportionalSetSizeKb.  The most common reason for this is that you forgot to quote a string value in the list of attributes being added to the slot1 ad.

According to one of our HTCondor wranglers, that error message is misleading and has yet to be corrected by CMS or WMCore people. Certainly, I've noticed it for a long time, but then I've been using the "new" VM for some while in the -dev application.

---

here, on the two machines which run CMS, the change from v50.00 to v60.00 happened without any problems :-)

here, on the two machines which run CMS, the change from v50.00 to v60.00 happened without any problems :-)

Happy to hear that, given that you have had problems in the past IIRC.
Have you implemented a squid proxy? That would have halved your download traffic to get both copies of the (1.6 GB) VM image. :-)

---

here, on the two machines which run CMS, the change from v50.00 to v60.00 happened without any problems :-)

Happy to hear that, given that you have had problems in the past IIRC.
Have you implemented a squid proxy? That would have halved your download traffic to get both copies of the (1.6 GB) VM image. :-)

no squid implemented yet, but I am still hopeful :-)

All CMS tasks seem to be just spinning without any CPU load. This started a few hours ago and they have run normally until then but not anymore. They run 18 hours and terminate with a much lower CPU time.

---

Same for me

Tasks that have started after my previous post are running normally at the moment. Fingers crossed.
Edit: All tasks where runtime is below 12 hours are calculating again. Those above 12 hours are idling, they will probably finish at 18 hours without further calculations,

---

Seems like the WU that started couldn't get any work on the back end and there is no retry then based on your observations

Something went awry for a couple of hours last night, judging from the job graphs. As far as I can see, it didn't affect other production nodes so it must have been something specific to us. Seems OK again now, though.

---

There was a firewall issue. Tightening up the rules went a bit far. Some of the rules were reverted and how everything should be fine.

Something similar like last Monday is happening again. But this time there are no new tasks on Boinc and CPUs are spinning idle without jobs to crunch. What's going on?

---

Yeah same here

Something similar like last Monday is happening again. But this time there are no new tasks on Boinc and CPUs are spinning idle without jobs to crunch. What's going on?

Just seen that myself. It doesn't seem to be a general problem, but the status I'm seeing from the cmsweb-testbed that we use to run our WMAgent is highly unusual. I'll send a few emails...

---

Something similar like last Monday is happening again. But this time there are no new tasks on Boinc and CPUs are spinning idle without jobs to crunch. What's going on?

Just seen that myself. It doesn't seem to be a general problem, but the status I'm seeing from the cmsweb-testbed that we use to run our WMAgent is highly unusual. I'll send a few emails...

OK, I've escalated it to a Service Ticket with CMS IT. No response as yet.

---

After years of trying, I finally completed and validated a CMS task on my Windows 10 PC. Congratulations!
Tullio

---

After years of trying, I finally completed and validated a CMS task on my Windows 10 PC. Congratulations!
Tullio

Oh, good! Any indication of what made the difference?

---

No, but I am glad to see something working on my PC. Recently I had to stop my ccoperation with QuChemPedIA@home because of a problem with security certificates, as outlined by Dave Anderson on the BOINC home page. I wrote them that I have 4 projects working on Windows and VirtualBox. I am glad that LHC@home has no such problem
Tullio

---