Troubleshooting external applications
There is no check for the consistency of the external application configuration when it is set up. If there are problems, these will first be seen by the end user, when the application is executed. For example, in a CLC Workbench, summary information will shown in a dialog. This may help to identify the issue. If this summary information does not help, try opening the Advanced tab, where an extended error message should be visible.
Below are some tips to aid with troubleshooting issues with external applications.
- Configure the external application to import standard out and/or standard error as text. This makes it possible to check error messages posted by the external application. See figure 15.56. For containerized external applications, messages from docker are posted to standard error, so collecting standard error for such applications is particularly recommended.
Figure 15.56: Standard error and standard out from the command line application can be collected and imported so it can be reviewed. - If your external application was previously working and then stops working, check if the configuration was recently changed. Each time a change is made the version number of the external application is updated. The name of the user who made the most recent change in the listing under the External application configurations area, and also under the Management tab of the editor for each individual external application. Only users with admin privileges are able to edit external applications configurations.
- Check the third party application/container can be run:
- For standard external applications:
- Is the application being found? Check that the path to the application is complete and correct.
- Is the application executable, and can it be executed by the user running the CLC Server process?
- If there is a wrapper script calling the third party application, does it contain the correct path to the application? Is the wrapper script executable?
- For containerized external applications:
- Does the user running the CLC Server have permission to run Docker? (Is that user a member of the docker group?)
- Is the reference to the container in the Command line field of the external application configuration valid?
- Is the CLC Server running on a Windows system? Containerized external applications are only supported for Linux-based setups.
- For standard external applications:
- Check the import/export directory configurations, where relevant.
- For standard external applications, the default temp dir is used by default for temporary files, but an import/export directory may be specified for this purpose instead, as described in Environment settings section. If this has been done, check the import/export directory is available and is writable by the user running the CLC Server process.
- For containerized external applications, an import/export directory is specified as the shared working directory in the containerized executation environment settings, as described in Configuring the containerized execution environment. Besides being available and writable by the user running the CLC Server process, the selected directory must be shareable between the host system and containers.
- For standard external applications, the default temp dir is used by default for temporary files, but an import/export directory may be specified for this purpose instead, as described in Environment settings section. If this has been done, check the import/export directory is available and is writable by the user running the CLC Server process.
- Check for conflicts in the naming of the external application.
If your users will only access external applications via a CLC Workbench, then you do not have to worry about what name you choose when setting up the configuration. However, if they plan to use the CLC Server Command Line Tools, to interact with your CLC Server, then please ensure that you do not use the same name as any of the CLC Server internal commands. You can get a list of these by running the
clcservercommand, with your CLC Server details and no tool specified. I.e. a command of the form:clcserver -S <host> -P <port> -U <username> -W <password or token>