FOGTaskScheduler causes always 100 % CPU usage

[KaiHerlemann]

Hi,
on our server, running on Debian 10.7 (we just switched from CentOS 7, there was the same problem), causes the FOGTaskScheduler always a 100 % CPU usage. We had this problem on our CentOS server for more than 50 days without interruption. The Debian one is still new, as I said. It’s a VM with 1 core, which is sufficient.
I found here a thread with related problem, but it’s not the same like that – the result of

mysql> SELECT * FROM scheduledTasks WHERE stActive=1;
...

is empty,

mysql> SELECT * FROM powerManagement WHERE pmAction LIKE '%wol%';
...

shows 158 entries. The newer one in pmMin column have an entry “00” instead of “0” or something else, but I think this is not the problem.
Two entries had no entry at all in the pmMin/pmHour/pmDom/pmMonth/pmDow columns. I deleted them, but it didn’t help.

We have 204 hosts in our database, not very much.

/var/log/fog/fogscheduler.log is not helpful, the content is:

[12-25-20 12:46:51 am] 
==================================
===        ====    =====      ====
===  =========  ==  ===   ==   ===
===  ========  ====  ==  ====  ===
===  ========  ====  ==  =========
===      ====  ====  ==  =========
===  ========  ====  ==  ===   ===
===  ========  ====  ==  ====  ===
===  =========  ==  ===   ==   ===
===  ==========    =====      ====
==================================
===== Free Opensource Ghost ======
==================================
============ Credits =============
= https://fogproject.org/Credits =
==================================
== Released under GPL Version 3 ==
==================================


[12-25-20 12:46:51 am] Interface Ready with IP Address: 127.0.0.1
[12-25-20 12:46:51 am] Interface Ready with IP Address: 127.0.1.1
[12-25-20 12:46:51 am] Interface Ready with IP Address: xxxxxxxx
[12-25-20 12:46:51 am] Interface Ready with IP Address: xxxxxxxx
[12-25-20 12:46:51 am]  * Starting TaskScheduler Service
[12-25-20 12:46:51 am]  * Checking for new items every 60 seconds
[12-25-20 12:46:51 am]  * Starting service loop
[12-25-20 12:46:51 am]  * 158 tasks found.

In opposite to the linked thread, we have no problems at all with the webgui, it’s only about high CPU usage. We also don’t have noticeable performance problems. But the temperature of the host cpu is much higher when fog is running

Thanks & keep healthy,
Kai

[Sebastian Roth]

@kaiherlemann said in FOGTaskScheduler causes always 100 % CPU usage:

Two entries had no entry at all in the pmMin/pmHour/pmDom/pmMonth/pmDow columns. I deleted them, but it didn’t help.

Did you restart the FOG server after that?

Which version of FOG do you use?

[KaiHerlemann]

@sebastian-roth said in FOGTaskScheduler causes always 100 % CPU usage:

Did you restart the FOG server after that?

I don’t remember if I restarted the FOG server immediately after that (I think so), but in the meantime I restarted it and it didn’t help.

Which version of FOG do you use?

We use fog 1.5.9.

[Sebastian Roth]

@KaiHerlemann A few weeks ago we had someone report an issue when adding power management (PM) tasks via the FOG API where hour was sent as “0” but ended up in the DB as empty value. We found and fixed what was causing this in the API as well as in FOG Cron class. Now I am wondering if the fix in FOG Cron class would also fix things in your case. Would you try applying it manually and restarting the whole FOG server (just to make sure)?

If this still doesn’t help I need to ask you to provide the full powerManagement table you have in your database so I can try to replicate the issue on my side as well. Use mysqldump to export this single table, upload somewhere and post a link here (or send it to me via PM).

[KaiHerlemann]

Problem is solved.
There were 24 rows in the table powerManagement like this:

+------+----------+-------+--------+-------+---------+-------+----------+------------+
| pmID | pmHostID | pmMin | pmHour | pmDom | pmMonth | pmDow | pmAction | pmOndemand |
+------+----------+-------+--------+-------+---------+-------+----------+------------+
|  510 |      106 | 7     | 30     | *     | *       | *     | wol      | 0          |

This is obviously nonsense, a day doesn’t have 30 hours. The hours and minutes were probably mixed up.

I said we had no performance problems – we had, I notice it now.

Thanks for your help!

[Sebastian Roth]

@KaiHerlemann Great you figured it out. Still something we should prevent from happening in the code.