Which process exactly causes this problem?
I had the same problem in the past, see here: https://forums.fogproject.org/topic/15031/fogtaskscheduler-causes-always-100-cpu-usage

Hi,

is there any possibility to use a certificate which is not self-signed by the fog CA?
Usually we use ACME to create certificates.

If it’s currently not possible, are there any plans to support it?
A possible problem would be that the certificates are only for one year valid. As the fog client AFAIK uses the certificate, it would be necessary to deploy the client with the new certificate.

Best regards,
Kai

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 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.

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