FOG Client log reporting old RC and odd behavior

[Wayne Workman]

Also see if the settings.json file inside of c:\ program files x86 \ fog is blank or not…

[fry_p]

@Joe-Schmitt FOG Service is running.

So it seems to start and run on boot ok.

[fry_p]

@Wayne-Workman It is blank. I take it that’s bad…

[Joe Schmitt]

@fry_p Yeah it’s bad. We’re starting to see this bug pop up now. I was hoping it was just a fluke as I am still unsure as what’s causing it.

[fry_p]

@Joe-Schmitt There seems to be no rhyme or reason to which clients this happens to. I am willing to give you any logs you need because this is becoming more and more widespread in the district. Does this explain random reboots?

[Joe Schmitt]

@fry_p for the reboots if the host is truely already on the domain, it may be possible that the server is sending bad data. See my bug report here:

https://github.com/FOGProject/fog-client/issues/76

[Wayne Workman]

@fry_p Is there a bunch of white space inside of settings.json? Mine wasn’t just totally blank but had a bunch of spaces in it.

[Joe Schmitt]

@fry_p I can push out a band-aid in a few hours that’ll prevent any more clients from loosing their settings file. We still need to find out the underlying server issue, but this patch will stop any more damage from being done.

[Wayne Workman]

@Joe-Schmitt How easy would it be to gather every GUID for every version of the new fog client?

[Joe Schmitt]

@Wayne-Workman Why?

[Wayne Workman]

@fry_p This particular computer you pulled the log from in the opening post, is it configured to sleep after a specified time of inactivity? Either through settings you put on the image it uses or via GPO? If so, what is that time length set to?

[Joe Schmitt]

@fry_p could you upload a copy of the blanked setting files along with a hexdump of it?

[fry_p]

@Wayne-Workman @Joe-Schmitt They are configured to never go to sleep or hibernate through group policy. Give me a moment for the settings file.

[fry_p]

@Joe-Schmitt

It says I don’t have enough privileges to upload to the forums.

[Joe Schmitt]

Odd. Could you still include the hexdump? Really that’s all I need.

[fry_p]

@Joe-Schmitt not much to see, flagged it as spam when I tried to copy paste it.

[Joe Schmitt]

@fry_p so that’s not good. The entire file is getting zero’d out.

[Wayne Workman]

So I’ve been thinking about lots of ways to try to detect when this happens.

The best idea I’ve had so far is to have a login script via GPO just copy each computer’s settings.json file to a share on the fog server, and have the fog server run a script every hour via CRON to do a checksum on every file, and then if any match the signature of one of the blank files, to just log it. This would give me a list of computers with the problem.

[Wayne Workman]

@Joe-Schmitt here is a copy of the file.

0_1477940167270_settings.json

The computer this file came from hasn’t been imaged in a long while, but we’ve tried deploying snapins to update things like Chrome several times, and also I sometimes deploy snapins with batch files for various things.

Here’s the log file. Joe, look at the end of the log.
0_1477940491375_fog.log

The log says that the client stopped working at 9/7/2016 4:50 PM

The teacher that uses this room says she’s only in here on Mondays and Wednesdays, and September 7th was a Wednesday. Maybe it’s coincidence, maybe the bug is somehow/someway related to being used or after being used.

Looking through the system logs, the Meraki service we have installed on all our systems is crashing a lot.

@fry_p do you have Meraki installed?

[Joe Schmitt]

@Wayne-Workman now that is very interesting. The Log API uses a different style of file writing than the Settings API does. So the fact that this is somehow happening to both is very surprising. I suspect some kind of outside interference.