This article presents troubleshooting guidelines for various issues that can occur with the Footprint Internal Scanners.

Internal Scanner containers are not updating

Problem: Internal scanner reports an outdated version of either the controller or the workers.

Solution: This problem usually occurs because the footprint-updater container has stopped working.

In order to investigate this issue, log into the VM’s terminal (e.g. SSH) and run the following command:

docker logs -f footprint-updater

A regular output should look similar to this:

Press Ctrl + C to exit the log view.

If your output does not match the one above, run the following commands to recreate the updater container:

docker rm --force footprint-updater 
cd /var/coda/internalscanner/workers/ && docker-compose up -d footprint-updater

The command above will recreate the updater container.

Alternative solution: If the log above complains about the .docker/ folder, this means that a misconfiguration has caused a wrong docker setup to be applied. Run the following command to clear any broken configuration and restart the updater container:

rm -rf ~/.docker
cd /var/coda/internalscanner/workers/ && docker-compose up -d footprint-updater

Internal Scanner reports N/A toolkit version right after installation

Problem: In certain cases, the internal scanner may report that the toolkit version is unknown or broken, even on a fresh installation.

Solution: Wait up to 5 minutes for the next pingback to the console to arrive. Alternatively, log into the console and manually run the toolkit executable:

cd /var/coda/ && ./coda_toolkit

Toolkit version is outdated/not present on active scanner

Problem: The internal scanner reports that the CODA Toolkit version is outdated or not present even after some time passed after installation.

Solution: CODA Toolkit is an executable which provides helper interactions between the host machines and the containers that communicate with the console. For example, it reads the actual hardware information in order to accurately report the machine specifications to the console.

The toolkit is run via cron jobs that you can view by typing the following command under the ubuntu user:

crontab -l

The output should look similar to this:

You can run the following command in order to force update and run toolkit. This will automatically update the cron configuration as well:

cd /var/coda/ && ./toolkit_updater.sh && ./coda_toolkit

Alternative solution: Make sure that the cron service is running. Further debugging information can be found in the /var/coda/logs/toolkit.log file.

Working Internal Scanner suddenly shows as Offline

Problem: A previously active Internal Scanner shows as Offline in the Footprint Console.

Solution: This can be caused by multiple factors:

• Check that the machine has access to the Footprint console

Network changes may have caused the VM to lose connection to the Footprint Console. You can open the internal scanner’s control panel at http://<ISC_VM_IP>:8080 to see connection information.

• Specifications are too low for the amount of jobs being processed

If you notice that the CPU/RAM has consistent high usage and the machine is not responding or processes very slow, try upgrading the VM or lowering the workload.

You can use htop to check the resource usage of the machine.

Alternatively, you can use btop (included in Internal Scanner VM’s newer than 1.3.12) for an easier to read output.

• Check that the docker service is running on the machine

Docker is required in order for the scanner to process jobs. You can view the status of the service by running the following command:

sudo service docker status

If the service is stopped, you can start it by running the following command:

sudo service docker start

• Check that the isc-backend container is running

The isc-backend container is the one that periodically pings back the Footprint console with its status. If this container is stopped, Footprint will automatically mark the scanner as Offline after a period of time.

To check whether the container is running, run the following command:

docker ps | grep isc-backend

The output should look similar to this:

You can manually start it by running the following command:

docker restart isc-backend

Internal Scanner installation via Windows Agent fails

Problem: After triggering the Install Internal Scanner command on a Windows Agent, the installation process does not result in a new entry in the Deployed Scanners page.

Solution: The Windows Agent has a series of prerequisites that are required before installing the scanner VM. If any of these prerequisites are not met, the agent listing page will show a notice on the State column of the scanners, as well as sending an alert with further details.

You can view the alert by filtering for the Agents module in the alerts page. The error will be similar to this:

The error will usually contain details on how to handle the specific situation.

Virtualization support on Windows Server

The most common error from installing Internal Scanners via Windows Agents is due to virtualization support not being enabled. Hyper-V and virtualization (nested virtualization if the Windows host is itself running inside a VM) is required in order to install Internal Scanners in Windows Agents.

You can follow the KB articles below for detailed steps on enabling virtualization:

• Enable virtualization on Windows 11 PCs

• Expose VMWare Hardware Assisted Virtualization

No space left on Internal Scanner

Problem: The Internal Scanner runs out of disk space.

Solution: The presence of various factors can lead to this issue, although the primary culprit is typically the logging and caching files stored within our scanner's containers.

• This problem usually occurs because of the advanced-scanner and zap-webapp-scanner containers.

To identify this you can run the following command:

docker ps --size

A regular output should look similar to this:

None of the containers should exceed 8 GB on the size column. If advanced-scanner or zap-webapp-scanner container has more space than 8 GB, you should restart it.

To restart the container you need to run the following commands:

• For zap-webapp-scanner

cd /var/coda/internalscanner/workers
docker compose rm -s -v zap-webapp-scanner # (Press Y if asking for confirmation)
docker compose up -d zap-webapp-scanner

• For advanced-scanner

cd /var/coda/internalscanner/workers
docker compose rm -s -v advanced-scanner # (Press Y if asking for confirmation)
docker compose up -d advanced-scanner

After restarting the containers you can check the disk usage by running:

df -h

DHCP netplan configuration not working

Problem: The Internal Scanner network doesn’t work.

Solution: Update netplan configuration in order to use mac as identifier for DHCP UID connection.

• This problem may occur with different DHCP server configurations.

The Internal Scanner uses the: /etc/netplan/60-coda-init.yaml netplan configuration file. We need to edit this configuration file and uncomment the line wth `dhcp-identifier`.

network:
  ethernets:
    eth0:
      dhcp4: true
      #dhcp-identifier: mac -> uncomment this line
  version: 2

In the end the 60-coda-init.yaml netplan configuration file should look like:

network:
  ethernets:
    eth0:
      dhcp4: true
      dhcp-identifier: mac
  version: 2

To apply the new configuration after you have edited the file please initiate a netplan try/apply.

sudo netplan try
sudo netplan apply