Objective :
The article describes step by step how to troubleshoot your environment when user dictionaries are not taken in account in your translation.
3 levels of investigation can be performed, as described below :
1) Checks on prerequisites
2) Gdict accessible through network
3) Resubmission of each of the profiles
1. Prerequisites:
1.1. Check and ensure that ALL services are up & running (green) in Advanced Configuration\Services :
1.2. Verify that FQDN_IP replaces "locahost" in Administration\Dictionary settings\GDict Settings\URL. Port 8892 needs to remain in settings.
Restart the service systran-ses-console to apply updated setting
systemctl restart systran-ses-console
1.3 Ensure dictionary is attached to profile
You can also temporarily disable the cache.
1.4 During translation, make you are calling proper profile, which has been attached with dictionary :
1.5 Ensure you have latest version of engines.
If not, upgrade to latest version.
2. Ensure network is open for Gdict:
2.1. Check through curl that gdict service is running and available locally :
curl http://localhost:8892/status
Output similar to {"app":{"name":"GDict Mongo","version":"XXXXX"},"status":true} needs to be obtained to confirm local proper service response.
2.2. From the server where TR engines are located (ie. backend if exists):
Check that that gdict is running and available
curl http://[FRONTEND_FQDN_IP]:8892/status
Output similar to {"app":{"name":"GDict Mongo","version":"XXXXX"},"status":true} needs to be obtained to confirm proper service response.
If this check turns out NOK, then there is likely a issue at firewall level, on port 8892.
Please apply the following :
firewall-cmd --list-all
Following entry needs to be present : "rule family="ipv4" source address="10.18.0.1/16" port port="8892" protocol="tcp" accept"
If absent, add the entry with following commands :
firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.18.0.1/16" port protocol="tcp" port="8892" accept"
firewall-cmd --reload
Then restart the TRM components :
systemctl stop systran-translation-resource-monitor.service \
&& docker network rm trm_proxy_network \
&& docker swarm leave --force \
&& docker network rm docker_gwbridge \
&& systemctl stop docker
systemctl start docker \
&& systemctl start systran-translation-resource-monitor.service
If this still turns out NOK, then there is likely a issue at firewall level, somewhere in the network
3. If GDict setting is updated, apply the new settings in the translation profiles:
For each of the active profiles, resubmit them all once again, one by one :
4. Ensure IP forwarding is activated on host
Check net.ipv4.conf.all.forwarding setting:
# sysctl -a | grep "net.ipv4.conf.all.forwarding"
net.ipv4.conf.all.forwarding = 0
If forwarding is inactive (=0), activate it:
sysctl net.ipv4.conf.all.forwarding=1
And ensure it is active after reboot by adding the following line to file /etc/sysctl.conf
net.ipv4.conf.all.forwarding=1
4. Check FRONTEND is reachable from Translation Resource docker container
SSH into running Translation Resource docker container and verify (FRONTEND) public IP and FQDN is reachable.
Check the running container processes and select a containerID whose image is "systran/pn9_ctranslate_gpu" :
docker ps
SSH into that Translation Resource container :
docker exec -it cd0e09a4b583 /bin/bash
Verify the FRONTEND is reachable from its public IP and also its FQDN :
[systran@cd0e09a4b583 systran]$ ping 147.135.155.234
PING 147.135.155.234 (147.135.155.234) 56(84) bytes of data.
64 bytes from 147.135.155.234: icmp_seq=1 ttl=57 time=0.539 ms
...
[systran@cd0e09a4b583 systran]$ ping sandbox234.mysystran.com
PING sandbox234.mysystran.com (147.135.155.234) 56(84) bytes of data.
64 bytes from sandbox234.mysystran.com (147.135.155.234): icmp_seq=1 ttl=57 time=0.585 ms
...