Known Issues

Services Description Solution
xpert-manager Edge Xpert Manager has been tested with Google Chrome only
consul
core-data
core-metadata
When a Device Service runs in a Docker container and uses nsenter, the Device Service may be unable to resolve the host names for the Data and Metadata services To resolve this issue, you can do either of the following:
  • Edit the etc/hosts file in the Docker container
  • Mount the hosts files as a volume to the container as a volume (recommended)

For further information, see the Registry Service topic in the Edge Xpert User Guide
xpert-manager
core-metadata
When using the Edge Xpert Manager and nsenter, there are issues connecting to the Metadata service and adding devices.

The Metadata logs show that the connection was refused or could not be found
Update the Device Service environment variables to use the IP address of the machine that the Device Service runs on.

For example if nsenter is not used, the OPC-UA environment variables define the following:
Host: "device-opc-ua"

If nsenter is used, this line must be updated to reference the local IP address, as follows:
Host: "<local IP address>"

For example:
Host: "172.18.10.2"
Device Services Device Service returns Error: 5:Failed to start HTTP server when running the container and both the --privileged and -p <port>:<port> commands are used Use only the --privileged command.

In the docker-compose.yml file, ensure that the privileged parameter is set to true, as follows:
device-opc-ua : privileged: true
Device Services If the names of deviceResource, deviceCommand or coreCommand are duplicated in any profile across all profiles, an error or warning message is logged.

This does not prevent the device profile from being uploaded or used in Edge Xpert.
To avoid the error or warning messages, ensure that unique names are used across all profiles.
redis If you want to access the Redis database directly, you cannot obtain a token to retrieve the password from Vault Modify docker-compose-security.yml to add EDGEXPERT_PASSWORD_FILE environment variable with value 'true' for the secretstore-setup microservice and restart Edge Xpert. Use the password, located at /tmp/edgex/secrets/redis-password and the default username redis5 to authenticate with the database.
Docker Toolbox If you use Docker Toolbox, you may encounter issues when running Edge Xpert under secure mode.

To identify any issues, open a terminal and enter the docker logs vault-worker command. Check the end of the log for the following:
    ...
    Executing custom command:
    Reading Redis5 password
    level=ERROR ..... msg="logTarget cannot be blank, using stdout only"
    Signaling secretstore-setup completion
    Finish chown secret files for each service
    Waiting for termination signal
    ...

If you do not see Waiting for termination signal, there is likely to be an X509: certificate signed by unknown authority issue
Clean all services, remove the security folder and restart Edge Xpert.
--secret
--api-gateway
On resource-constrained machines, services may sometimes fail to start when running Edge Xpert under secure mode.

This is due to service times timing out during the bootstrap process.
Start the services.

For example, to start the Virtual Device and run Edge Xpert under secure mode, enter the following commands:
edgexpert up --no-core --secret
edgexpert up --no-core --api-gateway
edgexpert up device-virtual
kong-db This issue is mainly seen on ARM32 systems. If it occurs, an entry similar to the following is added to the log:
    ...
    initdb: warning: enabling "trust" authentication for local connections
    You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
    waiting for server to start....
    1970-05-03 22:14:40.010 GMT [39] LOG:  starting PostgreSQL 12.6 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 32-bit
    1970-05-03 22:14:40.010 GMT [39] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
    ......................
    1970-05-03 22:14:40.010 GMT [39] LOG:  startup process (PID 40) was terminated by signal 11: Segmentation fault
    1970-05-03 22:14:40.010 GMT [39] LOG:  aborting startup due to startup process failure
    1970-05-03 22:14:40.010 GMT [39] LOG:  database system is shut down
    stopped waiting
    pg_ctl: could not start server
    Examine the log output.
Add the following lines to the kong-db section of the docker-compose-security.yml file:
security-opt:
- seccomp:unconfined

For further information, refer to the docker-library Segmentation fault on RPi information.
Back to top