This page describes common issues which may occur during day-to-day operations. As a rule before contacting Support you need to collect logs and other diagnostics information which may be relevant to the occurred issue. Also in case you have deployment in the not officially supported environment you may be required to reproduce issue in the supported environment.
Logs and diagnostic data collection
The following data may be required to be collected and provided while performing troubleshooting:
- elDoc server logs: stored in the ../elDoc/logs directory
- elDoc application logs: accessible via Administration → System logs
- 3rd components (MongoDB, Solr, mongo-connector[solr]) logs: stored in the respective folders according to the component's documentation
- OS level logs: stored according to the respective OS documentation
Know issues troubleshooting
This area will be extended with known issues and technics on troubleshooting the common issues.
1) Out-Of-Memory related issues
Out-Of-Memory issues are usually related to the IDP module and may occur due to not optimal configuration of the Recognition Rules, what creates high-load on the system as IDP phase is not optimized.
Recommendations are the following:
- Review and optimize recognition forms by adjusting keywords/minus-keywords;
- Suspend unused recognition forms;
- Review and adjust elDoc server system service configuration in terms of increasing allowed memory (-Xmx) and adjusting number of parallel threads for the IDP sub-system and whole elDoc server.
2) elDoc system service not starting after server reboot
In some circumstances you may found out that after server reboot elDoc system service (or other related dependency services) not starting automatically.
Issuing the following command "
journalctl -u eldoc.service" or "
journalctl -b" gives the output similar to:
After rebooting, performing a "
systemctl start eldoc" or "
systemctl status eldoc" command gives the following output:
The issue is very likely due to the service unit file, usually in
/etc/systemd/system , being a symbolic link to a non-root filesystem.
In the example below,
eldoc.service file is a symbolic link to the service file in
- Disable service and remove the symbolic links (service unit file and links created to enable it)
- Copy the
/etc/systemd/systemand reload systemd by executing "
- Add a drop-in to instruct systemd to start the service after mounting
- It is recommended to add the same drop-in into all custom service files created during elDoc system deployment
- After completing editing service files perform systemd reload and enable service to start automatically
Taking the steps described above will help to resolve described issue.