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.
3) Active Directory automatic synchronization fails
At some point administrators may find-out that automatic users directory synchronization with Active Directory can not be performed and the following log records appear in the system log:
An Invocation ID is an identification number that uniquely identifies a database within AD. Invocation IDs change during the restore process to make sure replication is consistent. It will only change when an Active Directory restore happens. In a restore process, it will change; the otherwise, the existing domain controllers will identify it as an existing domain controller and will not replicate the data over.
Log message shown above could be caused by change of the Invocation ID on the Active Directory side due to rollback operation or simply by changing the target server used for replication. To avoid such issues it is recommended to point elDoc to the specific AD-server which doesn't change randomly and take care about rollback procedures on the AD-side, and in case any performed - revisit elDoc Configuration page and manually perform full-sync with Active Directory.
Performing full-sync with Active Directory manually will store the updated Invocation ID and USN-number, as such all other scheduled synchronizations with AD will work fine.