This technique can be very helpful if a channel is experiencing live issues that you cannot resolve in the Iguana editor. These could be performance issues, intermittent errors, etc.

The technique is simple enough:

• Put logDebug() statements in your code
• Enable Debug level logging to start debug logging
• Disable Debug level logging to stop debug logging

Because the logDebug() function has very little overhead when debug logging is disabled, it is safe to use in production code. However it is advisable only to enable debug logging for short periods because of it writes a lot of extra data to the logs (which increases log size and reduces Iguana performance).

If a SQL database is experiencing performance issues, you can use the Iguana logs to track the performance of your SQL Statements.

To track your SQL database performance, first set the logging level for your channel to Debug. When the logging level is set to Debug, the SQL statements that are sent to the database will show up as Debug entries in the Iguana log files.

Because each entry in the Iguana log files has a time stamp, you can determine the amount of time needed to execute an SQL statement. To do this, examine the time stamp for the statement and then examine the time stamp for the next SQL statement in the log. The difference between the two time stamps will give you an estimate of the time required for this particular SQL statement to execute.

As of version 5.0.5, Iguana creates .log files with read-access granted to all users, while allowing only the owner to write to them (0644 for you old-schoolers).  Previously it would only grant read/write access to the owner, letting no one else access the files at all (0600).  This change does not introduce a security concern, however, since Iguana has always created the logs folder such that only its owner can reach the log files (0700)—if you created the logs folder yourself, you may want to check what access it grants.

Locking Down Access

If you created the logs folder yourself, you may want to deny access to anyone but the owner (chmod 0700 path/to/logs).  If you allowed Iguana to create this folder, this is already done for you.  Use “ls -ld path/to/logs” to verify; you should see something like “drwx——” for the logs folder.

Granting Access to a Group

Typically in cases where you want to share files with other users, you collect those users into a group.  To grant those users access to Iguana’s logs, you first change the group assigned to the logs folder (chgrp TheGroup path/to/logs), then you allow that group to enter but not modify the folder (chmod 0750 path/to/logs).  You don’t have to change the group name attached to each .log file; once in the folder, any user can read the logs.

References

The above examples should work on most Unixes; if they don’t work, your manual should be very helpful.  E.g., “man 1 chmod” will tell you all about those magic numbers above, and give you alternatives like “chmod g+rx path/to/logs” for granting read/enter permission to the log folder’s group.

Another way to grant access to the log folder is with Access Control Lists, or ACLs.  I never use them myself, but they are more flexible than the simpler, traditional Unix model describe above (ACLs are not universally supported).

You can prohibit Iguana or any Unix program from creating files with permissions you don’t like.  The “umask” command (man 1 umask) can be told which permissions not to allow.  Typically this is set to 022 (no write permission for group or other).  E.g., if you change that to 026 before running Iguana, Iguana will also not create files that “other” users can read (users who don’t own the file, or who are not in the group assigned to the file).  Use care with this as umask applies to every file Iguana creates, not just log files.  See your Unix manual for details.