Posts made by ablohowiak

@Wayne-Workman There are more results than this.

@Wayne-Workman
A few results.

@Wayne-Workman
Size doesn’t seem to matter, but I’ve used a group of 14 for this.

Once the page for the group is up. Click on membership.

And the resultanting web page.

The apache log has:
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/db/pdodb.class.php on line 544, referer: http://fog/fog/management/index.php?node=group&sub=edit&id=1559

…along with endless entries of:
PHP Fatal error: Wrong parameters for Exception([string $exception [, long $code [, Exception $previous = NULL]]]) in /var/www/html/fog/lib/client/printerclient.class.php on line 146

Server

• FOG Version: RC11
• OS: Ubuntu 14.04

Client

• Service Version:
• OS:

Description

The GUI is very responsive but, group membership times out and leaves a blank screen.

PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/db/pdodb.class.php on line 544, referer: http://fog/fog/management/index.php?node=group&sub=edit&id=1552

@Wayne-Workman
Had to run the delete commands one more time after moving to RC11. It’s been okay since then other than needing to reset the encryption data.

@Joe-Schmitt
RC11 has started out well. I did need to rerun the install and reboot the system before the client updater started working. The GUI remains responsive even after all the clients start up in the morning. After a few days I may try shortening the client communication period from 900 so the snapins run more timely.

@Wayne-Workman
Query one and four returned nothing. Here are the other three.

@Tom-Elliott
Now with the client communication set to 900 and finding the second client update checkbox things are behaving better.

@Tom-Elliott said in Gui not responsive:

@ablohowiak a bit out of norm but can you change the config.class.php filr to use 127.0.01? I suspect the sockets are dropping to make room for other sockets, causing some portions to just drop php code. So because the socket is lost mid stream it causes the GUI to crash. Again this is all theoretical but it files like an issue I’ve seen before, which was why I switched from a socket connection to a TCP connection

So changing the client communication to 900 sec didn’t improve the gui performance, nor did disabling the client auto updater. Do you still suggest changing the config.class.php, and if so are there particular line or every instance of the server IP address?
Thanks.

@Tom-Elliott
Yes, I’ve had confirmation from the tech.

@Tom-Elliott
Re-running the installer worked, Thanks!

@Tom-Elliott
Actually, the client response setting is having an impact for our techs with a lot fewer timeouts. I’m going to leave things as is and see what sort of feedback I get from a full day with these settings.

@Wayne-Workman
I’m on RC10 v 5955, but the symptoms have been there since RC9.

@Tom-Elliott
We have over 10k hosts. Load was an issue in RC7, and you suggested I apply (https://github.com/FOGProject/fogproject/commit/f39a26a27814a3d50333174fc461a0326d646d4a)

…and that worked.

Now since RC9 load isn’t an issue, but the http response has changed dramatically.

I’ve adjusted the fog client response time from 60 sec to 300 sec, but it doesn’t seem to have much of an impact.

More apache error log:

AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1. Set the ‘ServerName’ directive globally to suppress this message
[Mon Sep 12 12:56:50.109890 2016] [mpm_prefork:notice] [pid 1329] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.6.23-1+deprecated+dontuse+deb.sury.org~trusty+1 OpenSSL/1.0.1f configured – resuming normal operations
[Mon Sep 12 12:56:50.109910 2016] [core:notice] [pid 1329] AH00094: Command line: ‘/usr/sbin/apache2’
[Mon Sep 12 13:02:27.922592 2016] [core:notice] [pid 1329] AH00051: child pid 14456 exit signal Segmentation fault (11), possible coredump in /etc/apache2

Server

• Version: RC10 v5955
• OS: Ubuntu 14.04

Client

• Version:
• OS:

Description

In RC8 my server was overwhelmed with the load from all the student systems. Now at RC10 the load is better but the Gui will often time out. Here are some of the new errors I’m getting in the apache log:

[client ] PHP Warning: PDO::__construct(): MySQL server has gone away in /var/www/html/fog/lib/db/pdodb.class.php on line 152

[Mon Sep 12 07:53:55.853195 2016] [mpm_prefork:notice] [pid 10405] AH00169: caught SIGTERM, shutting down
[Mon Sep 12 07:54:15.715773 2016] [mpm_prefork:notice] [pid 1329] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.6.23-1+deprecated+dontuse+deb.sury.org~trusty+1 OpenSSL/1.0.1f configured – resuming normal operations
[Mon Sep 12 07:54:15.721722 2016] [core:notice] [pid 1329] AH00094: Command line: ‘/usr/sbin/apache2’
[Mon Sep 12 07:54:27.699003 2016] [mpm_prefork:error] [pid 1329] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

@Wayne-Workman
We were running 1.12, up until sometime this spring. Since then we’ve been on a trunk version. The last update was from RC8.

I would say over 10k clients. I’ve turned off the client updater for now. We’ll use something else to get the legacy clients updated to version 11.

Top was showing a load average of 147 when class was in session in RC8. Often mysql would be the highest cpu utilization, but then there would be dozens and dozens of apache2 instances. With RC9 the load average doesn’t climb so high, but there’s a bit broken too.

Server

• Version: RC9
• OS: Ubuntu 14.04

Client

• Version: varies
• OS: Windows

Description

My apache error log was just full of:

PHP Fatal error: Call to a member function get() on null in /var/www/html/fog/lib/client/updateclient.class.php on line 24

My GUI isn’t very responsive and is sometimes timing out.

@Wayne-Workman
No, I noticed these symptoms earlier, and given it has specific conditions to happen, there’s no way to pinpoint when or what caused it. When looking at the list of snapins the storage has a value, which is different from looking at the individual snapin.

@Wayne-Workman
This system has gone through multiple updates, I don’t recall when exactly this started to happened, and I know I’ve upgraded it since then. I’ll be fine fixing it myself, if all that’s needed is to repopulate the primary storage group.

@Wayne-Workman

I guess upgrading from 1.12 might have left old snapins blank.

All snapins are only on the master node.