Troubleshooting

Debugging

System Log

The easiest way to detect and locate problems is through the system log, available in the admin page. The lower the "log level" is for an event the more significant the event. A 1 denotes a serious/major event and a 0 would usually be a fatal error.

The "log.level" system variable (set through the admin page) is the highest level for which events are logged. In normal operation keeping this at 4 or 5 will ensure major events are logged but spurious information is not. This can be set higher for debug purposes.

Events log at a level of 0 to 10 - 0 is a fatal error and 10 is a very minor piece of information.

You can view the system log through the web interface, from the console with the logwatch tool or even manually via SQL queries to the fnlog table.

System Totally Broken

If your system is totally broken through an include file or such you may be able to see the error in the apache error log (usually /var/log/httpd/error_log) as you will not be able to see the log. In extremis you can view the system log as follows:

Login to MySQL
# mysql -u root freenats

Once logged in set the debug level to 10
mysql> update fnconfig set fnc_val=10 where fnc_var="log.level";

This should update the config level - go and try and login/start a script
mysql> select logevent from fnlog order by logid desc limit 0,10;

This will display the last 10 system events showing what files are included etc

Manual / Foreground Testing

You can run some tests manually or run the tester process in the foreground to get real-time debug output to the console. This is described in the advanced section of the documentation.

Common Problems

One or More Nodes Are Not Being Tested

Check the nodes are enabled. Check the system log for "tester already running" events and if found follow the "hung" process below. You can also set the log.level to 10 and see the process step-by-step in the system log (or manually - see the advanced section).

A Test Session Has "Hung"

If a test session has totally hung it may need to be killed from the Linux shell. More likely the process has died but left the node marked as still being tested. To clear these test sessions (the database locks) you can use the "test sessions" option on the admin page, click through the session in question and select manual close.

I am getting false alarms or Sometimes there is link trouble but the server is up

You can manually alter the settings for number of retries and timeouts for specific tests in their dialog (for more information see the tests documentation). You can mitigate false/network problem alerts with these settings and find a balance for speed-of-alert versus the robustness of the test. The node ping tests are a site-wide setting in the variables (as is the site-wide http timeout default) - see the administration section of the documentation.

Test graphs in a public view show an authorisation failure if I am not logged into FreeNATS

In order to enable graphs in a public view you must specifically enable graphs to be publically visible through the site.graph.public variable being set to 1. See the view documentation for more information.

I can't use the file manager to upload or save files

To use the file manager the directories you wish to edit/upload to must be accessible by the apache process. Usually this means you would have to allow global read/write (don't worry though - this is only to any program on your system, not to any user). You can do this with a chmod 777 either from the shell or FTP (if your system administrator allows it, many shared or highly secure environments won't).

For example:

chmod 777 /opt/freenats/server/base/site/tests
chmod 777 /opt/freenats/server/base/site/events

Would allow you full read/write access to the site tests and events directory (if they were located there).

I have edited a site include file and now the system won't start or parse

Edit your config.inc.php file (in server/base/) and add the line:

$fnSkipSiteIncludes=true;

At the bottom. Save the file.

This will stop site files from being included at startup regardless of the system variable configuration.

I have added IMAP tests and now testing fails or hangs

There was a bug with pre 3.3b VM appliances whereby IMAP wasn't supported. Please see this news article for information on how to patch the problem.

All nodes untested and/or "php command not found" error

If your nodes aren't being tested then try manually running a test, as described in the advanced topics section.

If this results in a "php: command not found" error or similar then you should try the conary steps detailed in this news article to patch the problem. If this doesn't work please report the problem via the support forum.

Other Problems?

Let us know if you find any more common problems via the forum and we'll list any here.