Log FAQs

This section contains answers to common questions about the Logs and Queues.

Keeping 365 days of logs should not be a problem. The only issue is if the log indexes get corrupted and need to be rebuilt, this can happen if Iguana crashes.

When Iguana is restarted it will need time to scan the logs and rebuild the indexes. As a rough guide, assuming we have 365 days of logs at 1MB per day (365 MB total) it should only take a few minutes to rebuild the indexes on a basic PC with a single disk drive. On a machine with a fast disks (RAID, SAN etc) it will be much quicker. The manual page Log Age and Logging Performance indicates that the indexes (metafiles) for 20GB of data were rebuilt in 15 minutes on a test machine.

So why do you need to keep logs for so long? Probably for legal reasons, so you may not need to track everything in the logs. This FAQ suggests some archiving alternatives, For legal reasons we need to record 7 years of messages, how can I do this?

Here are some alternatives

  1. Keep seven years of Iguana logs. Not recommended.
  2. Keep 60 days of logs and export and/or back them up regularly.
  3. Use the Translator to archive data to a database. Probably the best long term solution.

Please contact us at support@interfaceware.com if you need further help.

1. Keep seven years of Iguana logs

The Iguana logs are not designed for archiving. At the very least you need to copy or backup the logs also (see 2 below). Also keeping long term logs will slow down log index rebuilds, see I need to keep 365 days of logs, how will it affect Iguana? You can use Iguana to view and search the logs when you need to investigate.

2. Keep 60 days of Iguana logs and export and/or back them up regularly

Keeping a shorter period of logs and archiving them regularly makes much more sense.

Simply archive the logs by copying the <log directory>\log\<YYYMMDD>.log files to another location. When you need to do investigation you can use an Iguana server to view the archived logs. If you use backup software to “copy” the files you may need to restore the files before you can view them (we suggest restoring to an alternate location, rather than directly to the Iguana default log directory). An advantage of this approach is that it can easily be combined with your Iguana backup and restore routine.

As an interim measure you could export logs manually from within Iguana. Simply filter the log entries (eg: date range + messages only) using the search criteria, and then export the logs.

3. Use the Translator to archive data to a database

The good news is that the code is going to be simpler than mapping your interfaces. Probably all you need to do is to save every message as a string in its original format. Because you are using the Translator you can customize the archive process to your own needs, filter messages, add timestamps/comments/etc, route messages from different channels to different databases and so on.

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:

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.

Note: For information on using and viewing logs in Iguana, see the Logs section.

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.


The above examples should work on most Linuxes; 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 Linux model describe above (ACLs are not universally supported).

You can prohibit Iguana or any Linux 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 Linux manual for details.

It is Recommended Best Practice to encrypt the log files to secure patient information, and for HIPAA compliance. See Using Encrypted Storage for Iguana Logs for more information.

Leave A Comment?