A few things you may want to check:
- In the Task Manager > Processes are there any redis-server processes running? If so, kill them.
- Confirm that when restarting the FME Server Core and Engines, redis-server processes do not start.
- Will redis start on it's own?
- If you start redis-server (found in C:\\Program Files\\FMEServer\\Utilities\\redis by default) does it start? Is the port it's using open in the firewall (6379)?
- If it starts, can you start it by using "redis-server.exe" "redis.conf" from the command line? If not, see below:
- If you go to <FMESystemShare>/resources/logs, is there a queue folder? Does it have any log files in?
- If yes, what do they say?
- If no, it's like the service or system account running the FME Server Engine and Core Services doesn't have the correct permissions to create folders or repositories. Please double check the permissions.
- You can manually create the queue folder for logs and see whether FME Server will start writing log files there. If you're not sure where the folder is or naming conventions, you can check inside the redis.conf file by using a text editor (default location is C:\\Program Files\\FMEServer\\Utilities\\redis)
A few more things you may want to check:
- Is it permissions related? Are you using a named service account? Try adding the service account user to the local Admin Group on the local system. Restart the FME Server services and see if the problem remains present. If this resolves the problem, see the next item.
- Permissions related: Are the FME Server services being started with a service account? Ensure the service account user has permission to the ProgramData folder and the Program Files folder on the local system and is part of the User Group of the local system.
- not resolved by permissions check: Check with your IT Team for any changes that may have been made to the default local policy and local system permissions. Ensure the domain service account has been given the appropriate domain and local system permissions.
- Upgrading from an older version of FME Server? Occasionally, when uninstalling an express install of FME Server the database files may remain in place. The new installer doesn't replace the old files and when the new FME Server system is started it may connect to an older system database. This results in lots of different outcomes, but one is related to the inability of the redis queue to start and log messages in the fmeserver.log. To determine if this may be the cause, check the C:\\ProgramData\\Safe Software\\FME Server\\pgsql\\data for inconsistent dates (that don't match the dates of the new install and are much older, or connect with the timeline of the older FME Server software). If inconsistent dates are found on the subfolders, a complete uninstall, folder cleanup, and a new install will be necessary. Contact http://fme.ly/support if you have any questions on this.
The “Failed
to connect to job queue” problem was permission related. The FME Server system
share (Windows based) had a misconfigured owner. During the share creation process
normally a Windows AD user becomes owner of the share folder. For some reason the share folder had “root” as
owner. After changing the “root” user to a Windows AD user, FME Server was able
to create <FMESystemShare>/resources/logs/queue folder and start the redis-server.exe/job
queue.
Windows share owner comparison
The “Failed
to connect to job queue” problem was permission related. The FME Server system
share (Windows based) had a misconfigured owner. During the share creation process
normally a Windows AD user becomes owner of the share folder. For some reason the share folder had “root” as
owner. After changing the “root” user to a Windows AD user, FME Server was able
to create <FMESystemShare>/resources/logs/queue folder and start the redis-server.exe/job
queue.
Windows share owner comparison
