Open topic with navigation
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.)
The default location for synd.log is /usr/lib, but it can be located elsewhere if the environment variable SYNDLOG is set.
For more verbose debug logging, use the lmu -2 option. This command (and lmu -1) should be issued while License Manager is running.
(This command also starts debug logging for Synergy message manager. For more information on the Synergy message manager, see Messaging.)
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.
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:
Also see Displaying polling data and status for messages (such as “Reg string not found”) that display in lmu output.
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:|
|3.||Locate synd (or lmu) 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 message
This error occurs because either synd is not running or there are extra Synergy message queues. 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:|
If PATH is incorrect, reset it.
|3.||Start synd manually:|
|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:|
This displays the two Synergy/DE message queues used by License Manager. The output will look similar to this:
Queues: (ID=4 KEY=67113158<0x40010c6>) (ID=3 KEY=83890374<0x50010c6>) Synergy Daemon: (synd) pid 0
If either ID is -1, synd was unable to create the message queues.
|7.||View all the queues on the system:|
|8.||Find the Synergy queues. They can be identified by the pair of keys that start with 0x40 and 0x50, followed by a number, which is the same for both keys. For example:|
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
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.|
|11.||If the application still fails after these steps have been taken, call Synergy/DE Developer Support.|
LMFAIL error followed by MSGWAIT error
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:|
|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.
If you get this error on a new system that needs to be licensed, see When a system is cloned.
If you get this error after restoring a backup or reinstalling Synergy, see When a backup is restored or a system is reinstalled.