@Tom-Elliott I’ll solve it. I wanted to report so that there was some sort of record of this in the forums, because it’s possible that someone in the future could run into this.

I’ve fixed this in the code so fresh installs should no longer have this issue. That said this would not have caused any issues.

I’m solving this thread as the issue should be fixed. I imagine there may be issues in the future but only from a reporting standpoint. I have moved all of the states to use the task state class elements. Older data used to close tasks with a state is of 2. Task state is 2 is in-line so some of the reports may say this.

As far as I understand it, the printer management issues describes have been addressed. The problem being described is a bit vague but it seems there may be a configuration issue of one of the printers.

I’ve solved the thread for now but please feel free to post/unsolved with any more details.

I’m solving this thread for now. I would love to ensure there isn’t a problem with just the legacy client so if we can get more details I can probably squish this real quick.

I’m solving this as I have remoted in with @johnomaz and we verified things were finally working as expected. There was some issues but it was purely a configuration thing, not a fog bug issue. And I will state it’s a rarity that it isn’t something I caused.

At any rate I just hope it’s working properly for everybody now.

Service settings are now functioning again. Thanks for reporting.

@Tom-Elliott said:

I saw a portion of the problem and I believe this is now fully fixed too. While memory issues are not something I can fix for you, I did make the methods called a bit more efficient.

Tom is a bug murdering ace lately…

GUEST_6457171134_1266362531.gif

Yes they can be ignored. I am more interested in figuring out why they did not exist but that’s all that schema did.

@Tom-Elliott Thanks - git5135 fixed the snapin log:

“active snapins” are added/removed correctly -> OK snapins are running ok on the client -> OK the snapin log displays the database content correctly again (it added the new snapin tasks additionally to the ones from yesterday)** -> OK** the snapin status still is reported as “4” in snapinJobs and snapinTasks -> OK? no “sjHostID 0” entries in snapinJobs are created from hosts only started up/running -> OK

No more problems after update.

thanks !!!

@Uncle-Frank said:

mysqladmin -u root -p -i 1 processlist;

New thread started here
https://forums.fogproject.org/topic/6020/fog-svn-5020-and-above-cpu-hammered-thread/1

This has been fixed. It was an accidental mix up. I tested the code and found the problem and corrected. Then I overwrote my edits mistakenly and missed this file. Thank for reporting and it is now corrected for.

Okay. solved the host list issue by clearing the tables hosts and hostMAC and then reimporting the csv file.
The PHP error message is gone as well after updating.

Fixed
But new issue now - maybe better for another thread - php requests are slow to load now (including /fog/service/ipxe/boot.php - which sometimes times out)

@Tom-Elliott Thanks for the fix. It works now (git5040).

For the Database changes - they seem to be OK too:

snapinAssoc: removed snapin associations are deleted from table, Auto_Increment not increased hostMAC: the table entries for the hosts the snapin has been removed have been rewritten -> new hmIDs, Auto_Increment increased by the number of hosts in the group

@sudburr It is major, but I don’t think it would affect the DB stuff…

Maybe you can try this option tomorrow?

ok it seems good

Has this been fixed in the latest svn revision? Because I’m having this problem as well (2 NICS and a forever sending discover loop).

Yes sir it is.

Thanks Tom!

Yeah, it works 😉