Error logging and troubleshooting on UNIX

Error logging

By default, synd logs caught signals (15 “Software terminate”, 11 “Segmentation error”, and so forth) to the log file /usr/lib/synd.log and stamps each signal with the date it occurred. You may want to examine this file when you have licensing problems. (Note: “Software terminate” is a normal signal to receive; it usually occurs when you shut down the machine.)

By default the file is named synd.log and located in /usr/lib. If the log file cannot be written to that location, it will be created in /var/synergy. To control where the log file is created, as well as give it a different name, you can set the environment variable SYNDLOG. If the log file cannot be opened in any location, that error and all subsequent errors are written to standard error (stderr).

For more verbose debug logging, use the lmu -2 option. This command (and lmu -1) should be issued while License Manager is running. 

lmu -2

(This command also starts debug logging for Synergy message manager. For more information on the Synergy message manager, see Messaging.)

lmu -1

This command sends a reset signal to License Manager. It can also be used to help restart synd if it gets into a frozen state.

Important

Issuing two lmu -1 commands within 60 seconds of each other will start debug logging.

The log file can get quite large if you do not periodically clear it out. To clear the log and start with a fresh file without stopping synd, run this command while logged in as root:

>/usr/lib/synd.log

Troubleshooting licensing errors

This section lists some of the common licensing errors on UNIX and how to handle them. See also Displaying polling data and status for messages (such as “Reg string not found”) that display in lmu output.

Insufficient privilege

This message can occur when synd or lmu is not owned by root, the setuid bit is not set, or the correct permissions are not set. Either “synd” or “lmu” will precede “insufficient privilege.” Note that you can, as of version 11, run synd as a non-root user using an account that you create. This error occurs only when you are running synd as distributed, in which case it should be root with the setuid bit set.

Follow these instructions to correct the problem.

1. Log in as root or run su.
2. Move to the Synergy DBL lm directory and display a list of the directory: 
ls -la
3. Locate synd (or lmu, depending on the message you saw) in the displayed list, and verify that the owner is root. If it is not, change the owner to root. For example: 
chown root synd
4. Verify that the permissions for synd (or lmu) are set to rwsr-xr-x. The ‘s’ is the setuid bit. If the ‘s’ is missing, set it. For example: 
chmod u+s synd

%DBL-F-NOLMD Cannot access Synergy License Manager

This error occurs because either synd is not running or there is a problem with the Synergy message queues (such as an extra queue or two queues with the same ID). To correct this problem, do the following:

1. Check to see if synd is running: 
ps -ef |grep synd

If synd is running, you’ll see something like this:

root 10343     1  0 15:49:51   ttyp0    00:00:00 synd
2. If synd is not running, check your PATH setting. It should reference the lm and dbl/bin directories, which should be located in the same parent directory. For example: 
/usr/synergyde/lm;/usr/synergyde/dbl/bin

If PATH is incorrect, reset it.

3. Start synd manually: 
synd
4. Try to run your Synergy application again.
5. If the error still occurs, check again whether synd is running.
6. If synd is still not running, there may be a problem with the Synergy/DE message queues. Get the queue ID numbers: 
lmu -q

This displays the two Synergy/DE message queues used by License Manager. The output should look similar to this: 

Queues V1: (ID=4 KEY=67113158<0x40010c6>) (ID=3 KEY=83890374<0x50010c6>)
Synergy Daemon: (synd) pid 0
7. View all the queues on the system: 
ipcs -qa
8. Find the Synergy queues. They can be identified by the pair of keys that start with 0x4 and 0x5 (for 32-bit) or 0x44 and 0x55 (for 64-bit), followed by a number, which is the same for both keys. For example: 
0x44010c6
0x55010c6

Check the number of queues in use and the total number of bytes in the queues (in the CBYTES column). There may be extra Synergy queues that you do not need, especially if you’ve reinstalled. You need to either remove unnecessary queues or increase the number or size of the queues in the kernel. To increase the queue resources on your machine, check with your system administrator.

9. Be careful removing queues. Remove only queues that you are certain can be removed! If you are uncertain whether you have extras queues or which queues should be removed, stop now and call Synergy/DE Developer Support.

To remove queues enter

ipcrm -qq_number

where q_number is the ID of the queue you want to remove. You’ll do this twice—once for each queue ID in the pair.

10. Restart synd manually and try to run your Synergy application. If PATH, DBLDIR, and all permissions are set correctly, you should be able to run your application. If the application still fails, contact Synergy/DE Developer Support.
11. If both IDs were the same when you ran lmu -q, run lmu with the -fixinode option. (You need Synergy/DE [or the REV11 licensing upgrade package] 11.1.1d or higher to have access to this option.) 
lmu -fixinode

If this option is successful, you’ll see the message “Corrected license file inode”; your system should now be working properly. You can run lmu -q again to confirm that the two message queues have different IDs.

12. If -fixinode was unable to correct the problem, you’ll see the message “Warning! Unable to fix inode.” Try running lmu -altinode. (You need Synergy/DE [or the REV11 licensing upgrade package] 11.1.1h or higher to have access to this option.) 
lmu -altinode

You’ll see the message “Setting alternate inode flag.” This option should be able to fix the inode problem, although it may mean that pre-11.1.1h versions of Synergy will no longer be able to access the license file. To find out if this is the case on your system, run lmu -q again. You will see either “Queues V1” or “Queues V2” followed by the queue IDs. “V2” indicates that older versions of Synergy are no longer compatible. If you need to support older versions and your queue version is V2, contact Synergy/DE Developer Support.

LMFAIL error followed by MSGWAIT

These errors happen when synd takes too long to respond to either the Synergy runtime or to the lmu utility, and can occur when executing the install.sde script. This can be caused by a slow system or network.

1. If a retry or two aren’t successful, check to see if the synd daemon is running: 
ps -ef | grep synd
2. If the synd daemon is not running, restart synd manually, and then try to run your Synergy application again: 
synd
3. You can also set the MSGWAIT environment variable to wait longer for the communication before issuing the MSGWAIT error. Setting the MSGWAIT environment variable should be used only as a temporary measure until the slow network or system slowdown is corrected. If you have other applications using message queues, you may be exceeding the system’s maximum number of message segments. Try increasing the kernel parameter MSGSEG. (This parameter may have a different name on different UNIX platforms.)   

Machine’s registration string <...> does not match stored string <...>

A registration string mismatch error can occur when the registration string found on the system is not the correct one for that system. Typically, this occurs when an image of one system has been copied to another system or when an image was restored from backup and there has been a hardware change.

This error is logged to synd.log.