Updating to SVN 3542 - hung
-
If it works, maybe a minute or two… if it takes longer than that, it’s failed.
Update to the latest svn and try again. A mistake was made in a recent svn that caused the fog client download to try and try for something like 2.5 days… when it should have been 2.5 minutes lol… whoops. So svn up, buddy.
-
Done! Now I’m up to 3543. I get the following output when it reached the client download part.
* Downloading New FOG Client file...wget: --tries: Invalid number `-T'. wget: --tries: Invalid number `-T'. wget: --tries: Invalid number `-T'. wget: --tries: Invalid number `-T'. wget: --tries: Invalid number `-T'. wget: --tries: Invalid number `-T'. Failed to get client version
-
Well, at least it didn’t hang.
@Matt-Rozema: What distribution and version are you running? I think whatever you are using is using an older wget…
-
@cspence said:
Well, at least it didn’t hang.
@Matt-Rozema: What distribution and version are you running? I think whatever you are using is using an older wget…
Yeah, I’m glad it didn’t hang too.
I’m at revision 3543. -
@Matt-Rozema said:
Yeah, I’m glad it didn’t hang too.
I’m at revision 3543.Sorry, I meant Linux Distribution/Version (like Debian 7 for example).
-
Oh I see.
Ubuntu Server 12.04.2 LTS
-
Found the issue. Just forgot a number in the code. It shouldn’t cause any major problems.
Now keep in mind, for some reason, your machine is unable to query the web server during the install. I still need to figure out what’s going on with that…
-
What’s the url for the client download?
I can try a manual wget and see what happens. -
-
It just sits there.
wget http://127.0.0.1/fog/service/getclient.php --2015-06-12 15:12:13-- http://127.0.0.1/fog/service/getclient.php Connecting to 127.0.0.1:80... connected. HTTP request sent, awaiting response...
-
@Matt-Rozema said:
It just sits there.
wget http://127.0.0.1/fog/service/getclient.php --2015-06-12 15:12:13-- http://127.0.0.1/fog/service/getclient.php Connecting to 127.0.0.1:80... connected. HTTP request sent, awaiting response...
Can you do the same thing but with the IP swapped out for the one you said FOG would use?
-
Done.
I got exactly the same result. -
@Matt-Rozema Are you, by chance, behind a proxy?
-
It is happening to me as well. Confirmed that the webserver is completely unresponsive, no matter what fog-specific URL is requested. (The default apache page responds just fine).
Also confirmed the issue was introduced in r3542 (3541 works fine)
-
@Tom-Elliott Nope, no proxy here.
-
I think i found the problem; MYSQL.class.php changed its method to require a valid queryResult from reap_async_query before incrementing the processed counter. I admit to hypothesizing since i’m not intimately familiar with the code, but the return value of reap_async_query is only useful for queries that have return data. If an insert/update/etc query is getting passed in, i think it will always return FALSE - which will cause the process counter to never be incremented, causing an infinite loop.
</speculation>
-
Perhaps it’s time to start hosting the FOG revisions and kernels and inits on the new web service?
-
Should I give 3557 a shot? Thoughts?
-
@Matt-Rozema yes please.
-
Thanks Tom.
3557 works like a charm. My Fog server is back up and running.