Troubleshooting Server Controlled Publishing
To troubleshoot a problem with a worker script, you must first establish several things:
• The adapter or worker has been correctly installed and configured.
• The worker is configured to communicate with the Visualization server's Worker Agent.
• The Worker Agent is configured to remotely start the worker correctly.
• The worker is configured to perform conversions correctly.
Try these strategies sequentially:
1. Log on to the worker machine as the user configured to run the adapter in the Worker Agent setup. Start a new command shell, change directory to the <setup_directory>, and run the following command:
<batch_script> -vl worker_test.log -I
|
|
Do not run any special setup script before running the above command. The Worker Agent does not run the setup script before running the worker script. If you did not create the batch script, use the config tool to generate it.
|
This command attempts to run the adapter to print version information into a new worker_test.log file. Verify that this file was created and that it contains a list of approximately 15 library versions. Typical problems that can occur are:
◦ User file permission problems can prevent the adapter from recreating the log file.
◦ Extreme lack of disk space can make it impossible to create a log file.
◦ A corrupted installation can prevent the script from finding or having permission to execute necessary software components.
Generally, these problems are reported immediately on the command line, with no log file created. To prevent these problems, you must ensure that following conditions are met:
◦ There is sufficient disk space.
◦ Appropriate permissions exist on all components and directories.
◦ The adapter installation is not corrupt. Reinstall the adapter if necessary.
For more detailed information, refer to the section in this chapter on troubleshooting command line publishing.
2. Once you are confident that step 1 is working, verify that the worker can communicate with the Worker Agent. To do this, in the same command shell run the following command:
<worker_script>
This command attempts to connect to the Worker Agent and wait for instructions. Problems that can arise are:
◦ The configuration may not point at the Worker Agent correctly.
◦ The Worker Agent may not recognize the worker.
For v8.0 or later Visualization servers:
If there is a configuration problem, the error will be reported in the monitor_#.log log file. This log file typically contains one of the following messages:
Connecting to server "<server_name>" on port <server_port>
Failed to establish connection to client. <further details>.
The most likely cause for this message is incorrect server information in the worker. Check the machine name and port of the Worker Agent, and use the config tool to fix the error.
Connecting to server "<server_name>" on port <server_port>
Connection established
Got version 8 INIT FAILURE (with no description) from WVS.
This message indicates that the Worker Agent has not been configured correctly and is refusing to communicate to the worker. Refer to
Visualization Server Definition for more information on fixing this issue.
Connecting to server "<server_name>" on port <server_port>
Connection established
Got INIT SUCCESS reply
This message indicates that the connection was successful, and that both the worker and Worker Agent configuration are correct.
When everything is working correctly, the worker script keeps running, with no output to the command shell, until it is stopped.
|
|
The config tool has a test server feature which can be used to verify the server settings.
|
For Pre-v8.0 Visualization servers:
If there is a configuration problem, it will be reported in the helper_#.log log file. This log file typically contains one of the following messages
Invalid hostname "-CS<server_name>".
or
Connecting to server "<server_name>" on port <server_port>
Could not connect to server at port <server_port> on host "<server_name>". <further details>.
The most likely cause of this message is that the worker's server information is incorrect. Check the machine name and port of the Worker Agent, and use the config tool to fix the error.
Connecting to server "<server_name>" on port <server_port>
Connection established
Started worker
Worker has connected.
Helper: Connection to server has been rejected. Shutting down...
This message indicates that the Worker Agent has not been configured correctly and is refusing to communicate to the worker. For more information on fixing this issue, refer to
Visualization Server Definition.
Connecting to server "<server_name>" on port <server_port>
Connection established
Started worker
Worker has connected.
This message is the same as the previous one, without the error message, and means that the Visualization server did not reject the connection. To verify that the worker has been accepted, go to the Worker Agent's worker page to check that the worker has been flagged as started. If not, the Worker Agent has not been correctly configured.
When everything is working correctly, the worker script continues to run, with no output to the command shell, until it is stopped.
3. Once the communication between the worker and the Worker Agent has been verified as working, you can check for problems with remote execution. The likely causes of problems here are:
◦ On Windows machines, the Worker Daemon has not been installed as a service, or is not running.
◦ On UNIX machines, telnet services are not enabled.
◦ The Worker Agent has been incorrectly configured.
◦ Access to the display is required by the adapter and is not allowed.
◦ On Windows machines, part of the installation might be on a network drive to which services have no access.
On a Windows machine, verify that none of the worker installations is on a networked drive. If the worker is running on a different Windows machine to the server, ensure that the Worker Daemon is installed correctly, is running, and that you know which port it is listening on. The setup program page Select Worker Daemon Options lets you do this. If you do not know whether the Worker Daemon has been started, check the service in the computer's Computer Management tool.
On a UNIX machine, make sure that you can telnet to the worker machine by running telnet from a command shell on the Visualization server. Make sure that you have the correct user name and password to log on.
Once you have established that the worker machine can accept remote execution commands, check the Worker Agent's configuration, making sure that all details of hosts, ports, user names, and passwords are correct. If all these details are set up correctly, you will be able to start the worker remotely from your Visualization server.
If the worker has started successfully, you should see these log files in the <setup_directory>:
◦ helper_#.log—Log file created by the workerhelper program.
◦ worker_#.log—Log file created by the adapter.
If the worker fails to start, check these log files for any error messages, fix any errors reported, and retry. One common problem, often difficult to diagnose, is a requirement by the adapter to access the display. To address this, choose one of the following:
◦ On UNIX, try adding the following line to the top of the worker script:
setenv DISPLAY :0.0
◦ On Windows, enable the LogOn setting Allow service to interact with the desktop for the Worker Daemon service.
4. Once the worker can be started, verify that it is working correctly by publishing a simple file. If the worker fails to publish a file, copy the data to the worker machine and use the batch script to convert the data on the command line. Any conversion failure can usually be reproduced using the batch script. If it does reproduce the issue, refer to the section on troubleshooting command line publishing to fix this issue. In the case of Windchill, once the worker is up and running, you should use the Worker Agent test to send a test file to the worker. Once that is successful, publish the data that is in Windchill.
If you still have problems, contact Technical Support.
