@devle So I’m unable to replicate this:

[03-26-26 11:46:47 am]  * 1 task found.
[03-26-26 11:46:47 am]  * Checking for expired checked-in tasks...
[03-26-26 11:46:47 am]  * Scheduled Task run time: Thu, 26 Mar 2026 12:00:00 +0000
[03-26-26 11:46:47 am]  * This is a cron style task that should not run now. 
^C
telliott@7550precision:~/fogproject$ date -u
Thu Mar 26 11:46:57 AM UTC 2026
telliott@7550precision:~/fogproject$

The item I have:

MariaDB [fog]> select * from scheduledTasks\G
*************************** 1. row ***************************
         stID: 2
       stName: Multi-Cast Task
       stDesc: 
       stType: C
 stTaskTypeID: 8
     stMinute: 0
       stHour: *
        stDOM: *
      stMonth: *
        stDOW: *
    stIsGroup: 1
stGroupHostID: 1
    stImageID: 0
   stShutDown: 
     stOther1: 
     stOther2: -1
     stOther3: fog
     stOther4: 1
     stOther5: 
   stDateTime: 0
     stActive: 1
1 row in set (0.000 sec)

@Infojoe Unfortunately my test environment where I would normally work on these things hasn’t been behaving nicely.

Luckily, however, a fellow developer @rodluz was able to narrow the “what” and I believe I have fixed it.

The issue at least based on what was found:

PHP 8.1 deprecated the FILTER_SANITIZE_STRING feature and I replaced it with FILTER_SANITIZE_SPECIAL_CHARS or something alike to it.

This was the expected change at the time, but forgot that special characters may show up in Session variables (among other variables)

So say an & would get created, well FILTER_SANITIZE_SPECIAL_CHARS would encode & to & which would then see the & again and perform the same trick over and over and over in a recursive loop.

This is what was causing the CPU spikes, my apologies for that oversite. This has been addressed within the latest dev-branch if anyone would like to kick the tires?

Thank you!

Is everyone having this particular problem consistently using the LDAP plugin by chance?

@rogalskij I don’t know OS:

PHP error logs
/var/log/php-fpm/www-error.log (redhat based)
/var/log/apache2/error.log (debian based)

SQL:
SELECT * FROM history;

I doubt the sql will be of much help, but anything is better than nothing.

Most of the logs I’ve gotten this far don’t appear to have anything and maybe none of them do, in which case I don’t know when the issue was directly introduced.

If anyone is able to bisect known good and the obvious current as the starting bad to figure out when it got introduced?

I’m assuming we’ve all tried reverting to the first known good and verified it is still “good” as well?

Basically if someone doens’t mind taking where they know they’re broken, and iterating back to when it works great to exactly when it fails, it may help us figure out where to start otherwise I’m currently flying blind.

@rogalskij The number in front of all hosts (and groups/snapins/images/etc…) is the Database ID of the object in question, that’s expected.

I’m trying to follow what caused this and I’m having a difficult time reproducing it.

Can you all edit /var/www/fog/lib/db/pdodb.class.php at line -> 125:

change:

PDO::ATTR_EMULATE_PREPARES => false,

to:

PDO::ATTR_EMULATE_PREPARES => true,

I’m pretty sure this is going to break other things, but it will give me a data point I’m trying to narrow down.

Can you get some output from /var/log/php-fpm/www-error.log (if redhat based?) or /var/log/apache2/error.log (if debian)

Basically try to load the page, and tail the log and return that output here for htat rough timestamp.

Also see if there’s anything in the history table:

SELECT * from fog.history;

For around that time frame.

@olivier-bonnici How many hosts do you have?

@tatanas @Infojoe as well, apologies on delayed response.

@JGeear I don’t know who changed what or when or why.

You can look at the history table to get a guess as to when it might have happened, but I don’t believe it’s as direct an audit of what changed specifically, just that the Storage node was updated.

@mashina I have made an update after being able to replicate the problem you described.

Issue it seems was an error 500 occuring on line 329 of the taskingelement.class.php element because it couldn’t find a relevant imaging log.

I’ve added code that seems to be able to address this though not sure what is actually wrong otherwise. WIth the patch I made things seem to complete okay so I think it’d work good for uni and multicast tasks if you’d be willing to update and test?

@mashina Okay so just so I fully understand:

The database is successfully updating, but for some reason it’s not returning the exit code correctly.

I don’t know why (I do want to fix the error you’re seeing but it doesn’t appear to be causing a true “problem” just causes the machine to appear like there is a problem when after the reboot actually occurs), however all is perfectly fine just it might take a minute or 2 longer to actually get into a bootable/workable system?

So your issue is not at all related though the messaging is similar (Failed to update database) but its failing because it believes the task no longer exists (which indeed is true although only in the context that it is successfully completing the task, but not sending the expected code FOS is waiting for.)

(I know I’m seeming to ramble, just trying to get my thoughts out and help steer the issue toward whats actually wrong so we know where to look to hopefully fix it.)

The database is updated, but because FOS doesn’t get the code it expects, it thinks it needs to retry. The retry has nothing to associate to any more (Hence the no active task.)

@mashina The history table issue’s I’m seeing appear to be legitimate:

You wouldn’t be able to deploy snapins to a host if the snapin isn’t associated to a host. That said, I don’t know exactly what deploy type, nor what actual “version”

while I can checkout the commit hash, it’s just a hash and not somethign I readily memorize.

your exact version of FOG would show on the bottom right of the UI when you login.

I believe your commit hash relates to working-1.6-beta.2273 or something like that.

That’s within 2 of the actual “current” but also notably it is within the save function rewrite. Which we definitely see in the history writing.

It appears like you’re trying to do a Multiple Snapin Task and this is failing?

@JGeear I don’t know if anything changed, just I wonder if someone was making an edit in the UI and accidentally changed the password in the UI. I’m having you start with where I know the system is getting the information. Make sure the username/password matches what is on that nodes /opt/fog/.fogsettings file. If they are the same, then I’d ask if you can use that same information and an FTP client to ensure at least connection is there. Then we can try to troubleshoot further.

@mashina Can you get select * from history; out of your database?

I’m having a sneaking suspicion the issue is likely part of a rewrite to substaintially make save our save to database functions, that has some repercussions on other things because so much had required things that shouldn’t have bene required.

Similarly, can you provide the exact version?

“Latest working-1.6” is a shifting target. like i’m pretty sure you were not on the latest since I made pushes today so pretty sure the error you are getting is not related to today.

@JGeear your FOG Storage Node -> username/password is where the ftp_login information comes from.

@mashina Similarly for you, but I call out about the “same message” becasue working-1.6 is using ssh unless you’re on an older (1 year or so ago) version of working-1.6?

@mashina Are you sure it’s giving ftp_login error?

@Redbob The username/password should match an authentication you use for the FOG GUI.

@Greg-Plamondon I’m going to try delving into this but I’ve been very busy with other things and just haven’t gotten around.

I do appreciate the patience and assistance.

The changes you were doing that fixed the problem, please implement them again and you should be back to functional

Once that is done, do you mind doing a diff between that file and the relevant file in the git repository side:

Files I think you changed were under: <path>/<to>/<installer>/packages/service/<servicename>/<servicefile>

I’m not seeing any issues on my test systems.

not really sure why it isn’t working either.

I believe you were editing the files in /opt/fog/service/<servicename>/<servicefile>

So you would do:

diff -u <path>/<to>/<installer>/packages/service/<servicename>/<servicefile> /opt/fog/service/<servicename>/<servicefile>

@xavier-duthilleul I suspect it’s your /etc/fstab is looking at a UUID instead of a physical medium.

The one drawback to the uuid method of bootloading (which is great to always ensure you get the same files) is that the UUID’s are not the same between systems.

@Greg-Plamondon I’m not sure I fully understand:

When I look at the dev-branch files I see that the sprintf method you are doing for PingHosts is what is happening for ImageSize/ImageReplicator

The code you’re changing is within the sprintf stanzas?