Huge database entries number
-
@siarkowski Iām not aware of anything that might be causing this.
The fact that your taskTypeID == 0 in these cases is interesting.
FOG doesnāt have a ācreate a new taskā from Checking in or anything which makes me think what youāre seeing is a symptom, not a cause.
The way tasks get created is either via UI, API, or (similar to UI/API pair) by having a scheduled task.
We have (although it may need more refinement) checks to make sure that type of task that does get created are valid (of which taskTypeID 0 != valid task)
Can you check your scheduled tasks table and see if maybe something there is doing this at some time?
The fact the task was created at 2026-01-02 09:52:02 looks like it could be a schedule task that somehow has a now invalid task type id thatās just managing to get through.
-
@Tom-Elliott
Thanks for replay.In the tasks menu, scheduled Tasks there are no entries. However but in database table scheduledTasks the are two entries:
Ā±-----Ā±------------Ā±-------Ā±-------Ā±-------------Ā±---------Ā±-------Ā±------Ā±--------Ā±------Ā±----------Ā±--------------Ā±----------Ā±-----------Ā±---------Ā±---------Ā±---------Ā±---------Ā±---------Ā±-----------Ā±---------+
| stID | stName | stDesc | stType | stTaskTypeID | stMinute | stHour | stDOM | stMonth | stDOW | stIsGroup | stGroupHostID | stImageID | stShutDown | stOther1 | stOther2 | stOther3 | stOther4 | stOther5 | stDateTime | stActive |
Ā±-----Ā±------------Ā±-------Ā±-------Ā±-------------Ā±---------Ā±-------Ā±------Ā±--------Ā±------Ā±----------Ā±--------------Ā±----------Ā±-----------Ā±---------Ā±---------Ā±---------Ā±---------Ā±---------Ā±-----------Ā±---------+
| 1 | Deploy Task | | S | 1 | | | | | | 1 | 6 | 0 | | | -1 | fog | 1 | | 1681921800 | 0 |
| 2 | Deploy Task | | S | 1 | | | | | | 1 | 8 | 0 | | | -1 | fog | 1 | | 1741105800 | 0 |
Ā±-----Ā±------------Ā±-------Ā±-------Ā±-------------Ā±---------Ā±-------Ā±------Ā±--------Ā±------Ā±----------Ā±--------------Ā±----------Ā±-----------Ā±---------Ā±---------Ā±---------Ā±---------Ā±---------Ā±-----------Ā±---------+ -
@siarkowski Thanks, the scheduledTasks youāre showing arenāt showing anything out of the ordinary other than these were āDelayedā tasks
First was delayed to run at 2023-04-19 16:30:00 (UTC)
Second was delayed to run at 2025-03-04 16:30:00 (UTC)I am pretty sure, this isnāt the issue youāre seeing at least.
So I wonder if thereās some corruption due to running out of disk space thatās causing this?
-
@Tom-Elliott
I finished all running deploy tasks, cleaned task table.
At this moment partition was over 5GiB free disk space.
I started 37PCs deploy task and the story is same again. Database tasks table files were 40kB before I started the task and after 30 minutes database tasks table files are over 4MB.
Services work fine, tasks are processed, but tasks table is over 26000 records long and itās increasing.
Iām pretty sure if I start task for 200 PCs disk will run out of space after few hours
-
@siarkowski I understand what youāre saying, what I donāt understand is why this is happening at all. If this was a normal issue, weād have been notified of this issue probably many many times.
Iām not saying this couldnāt be a bug, I just have no way to replicate the issue in a consistent manner.
Might you be able to pull a backup of your database using FOG Configuration -> Configuration Save -> Export
(After cleaning up the Task issue) and see if you can use a secondary system to import that DB and (as a test) and ensure all the data you require is there (not necessarily the physical images)).
I donāt know what to suggest or say here other than I suspect the database is corrupted and itās that corruption adding and exploding task records. This (again) isnāt to say there isnāt a bug, but I want try to start with a clean baseline and see if things worked properly under āsanitizedā environment.
If a fresh server (if you can share your images that much better) works without adding/exploding the task table, that at least proves itās a DB Corruption issue. If it, too, starts exploding in task table records, then it shows thereās something in the code thatās doing this unexpectedly but at least we narrowed the scope to exactly where to being looking (somewhere in the task checkin process it seems?)
-
@siarkowski
Corrupeted DB or schema is highly possible.
Iāll backup tables: users, hosts, groups and images data and make a fresh FOG install.
I"ll let you know as soon as Iāll do it. It will be no sooner then next week Iām afraid. -
@siarkowski Thatās perfectly understandable and much appreciated. Sorry I donāt have a simple āhereās what to doā right now, and maybe a fresh install will fix the issue altogether, but right now it we have limited information. Thank you again for your understanding a patience with this as well.
-
@Tom-Elliott
As a curiosity, after two hours of 37 PCs deployment , 10 are finished, 10 are rolling, 17 are waiting. Tasks table is 815000 records long and tasks db files are 138MiB total.
Donāt get me wrong, FOG is awesome tool - seriously. -
Hello All,
First hit.
I uninstalled FOG, dropped database, installed FOG again, imported users, hosts, images, started task for 31 PCs and records with taskimageID equal to 0 are being inserted again.
Second hit.
I imaged OS disk, installed fresh operating system, installed FOG, imported users, hosts, images, started task for 31 PCs and records with taskimageID equal to 0 are being inserted again. Third hit.
I reverted all changes, installed FOG but rev. 1.5.10.1622, imported users, hosts, images, started task for 31 PCs and no records with taskimageID equal to 0 are being inserted
Not to be so happy another issue appeared, tasks do not start automatically I have to force it to start, but itās different story. -
@siarkowski I believe I have found the cause of this.
A while back, right after the version you reverted too, we added an improved queueing system. It was a simple syntax error (the wrong$task->idvs$task->get('id')).This should also greatly improve the experience of the imaging task queue (see also https://github.com/FOGProject/fogproject/issues/736 and https://github.com/FOGProject/fogproject/issues/691) I thought I also wrote a post somewhere in the forum walking through the updated process that fixed some longstanding date math issues, but I canāt find that now.
Point being, if you would be so kind as to update to the latest dev-branch version and see if it fixes the issue, that would be very helpful.
