Updating to SVN 3542 - hung

[cspence]

http://127.0.0.1/fog/service/getclient.php

[Matt Rozema]

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... 

[cspence]

@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?

[Matt Rozema]

Done.
I got exactly the same result.

[Tom Elliott]

@Matt-Rozema Are you, by chance, behind a proxy?

[contewit]

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)

[Matt Rozema]

@Tom-Elliott Nope, no proxy here.

[contewit]

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>

[Wayne Workman]

Perhaps it’s time to start hosting the FOG revisions and kernels and inits on the new web service?

[Matt Rozema]

Should I give 3557 a shot? Thoughts?

[Tom Elliott]

@Matt-Rozema yes please.

[Matt Rozema]

Thanks Tom.
3557 works like a charm. My Fog server is back up and running.