Skip to main content

Troubleshooting

Dealing with locked files

When idfilerep cannot replace a file because the file is locked by some process:

  • If there is no .busy extension version of that file, it leaves a copy with the .busy extension.

  • If the .busy version already exists, it leaves a copy with an .nnnn extension.

The timestamps on the files can usually be reliable enough to determine which file is newest by checking the creation time.

For an administrator to restore the correct version of the file, the newest file has to be renamed with the original file extension; for example, exe, dll extensions. The rest of the files should be removed to a backup location in case there was something important in any of them; they act as a tiny history for that file.

Tracing file propagation activity

You can find file "sync" activity (success/failure, per file) in the idmsuite.log. Look for entries logged by:

  • The updinst utility.

  • idfilerep on the receiving node end (by default listening on port 2380). See idfilerep entries in the secondary nodes’ idmsuite.log that handles placing those files in their correct locations.

  • updproxy on proxy servers. Check its entries on the primary node's log. The receiving end is the proxy entries in the proxy log.

    Unlike updinst , which replicates with parallel threads, updproxy updates serially, one file at a time, so it can take much longer to update an application proxy than a node, especially the first time the proxy is added or when the updproxy is forced to send all files.

    However, updinst is used on the primary node for retrieving log files from both secondary nodes and application proxy servers.

In this section: