@wayne-workman
Thx. I figured out where was the issue. Maybe this info will help somebody.
I use curl under Windows, but command line doesn’t support single quotes '.
I used " and had to escape inner ones
–data “{\“hostID\”:13}”

@Wayne-Workman
I think i cracked it, after you mentioned DB connection issues i checked everything using workbench and found fogstorage user had no schema privaleges at all ! Not sure how they would dissapear but after adding back in fog seems to be picking other storagenodes correctly.
Thank you for the help and guidance.
This can be marked as no bug but maybe helpful for others to check if they encounter issues.

Worked with @theWizard yesterday via remote session.

Found that the snapins were being uploaded to another storage node. That storage node /opt/fog/snapins folder had incorrect permissions on it.

Fixed the permissions and confirmed the working on working-RC-24. I’m solving this thread.

Found and fixed for RC-22.

@Tom-Elliott
Yep i ran through your instructions and made any relevant changes but the thing that fixed it was adding the user back to mysql, not sure why it disappeared though.

@Tom-Elliott
Hi Tom, just wanted to make you aware whatever changes were made recently in regards to additional mac addresses have fixed this issue now in 1.3.4-RC-2 thank you.

@Tom-Elliott Ok thanks look forward to it your doing lots of great work.

This is why the Debugger was made. Note that there is a bug in the Debugger starting at 0.11.0 with exiting so for the below instructions please use the one from 0.10.6 (https://github.com/FOGProject/fog-client/releases/download/0.10.6/Debugger.exe)

Make a snapin with the following settings:

Snapin File: Debugger.exe Snapin Arguments: user list > C:\user-dump.txt

Deploy this snapin on a problematic host. A listing of the logged in users will be in C:\user-dump.txt.

With any luck, I hope to have found a potential partial cause of the load. Again, this only appears to happen on Ubuntu based systems, but why I couldn’t tell you.

By moving the servicemodule-active.php file I can limit the load, but I think it’s not a suitable test because it essentially keeps the FOG Clients from doing anything related to the work the modules are expected to do.

This seems, to me, to be two part. First the servicemodule-active was calling at least 12 separate calls to the database per system. I’ve now limited this to a single call to the database to return all the values. The second part that I have no good way to test is the php versioning.

While most are running 5.6.20 (or very close to it), the values should be operating in normal ranges. However, the output of Fedora 23 system running PHP 7 (sorry I don’t feel like downgrading to php 5 for now).

PHP 7.0.5 (cli) (built: Mar 30 2016 09:13:39) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

The output of PHP 7 on Ubuntu 15.10

PHP 7.0.5-2+deb.sury.org~wily+1 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Notice the “extra line” of “With Zend OPcache v7.0.6-dev, Copyright” stuff.

I don’t know if that’s actually supposed to do that. Meaning, I believe the Zend OPcache value should match the php version as php is written by Zend (or so I thought). In either case, it’s intriguing to say the least.

Confirmed, found, fixed, and pushed (even if it doesn’t really get used any more.);

See my post here please: https://forums.fogproject.org/topic/6781/php5-gettext

Please let me know after updating…again. I say again because I found I had one thing being encoded where it shouldn’t have been which would cause the failure because it’s passing the password that will NOT be decoded. When it’s performed on command line, however, it needs to be encoded.

I think the problem was launching a powershell script that then launched another script as a domain admin but the credentials wont populate when it is being run from the system account just asks for password in a non visible console.
I have compiled the main powershell script as an exe which is then run via the system account and seems to be working now with the exception of not running as domain admin.

Any chance you could point me in the right direction as i can’t find where to make those changes at all .