This article presents troubleshooting guidelines for various issues that can occur with the Footprint Internal Scanners.
- Internal Scanner containers are not updating
- Internal Scanner reports N/A toolkit version right after installation
- Toolkit version is outdated/not present on active scanner
- Working Internal Scanner suddenly shows as Offline
- Internal Scanner installation via Windows Agent fails
- No space left on Internal Scanner
- DHCP netplan configuration not working
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:
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
andzap-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
Comments
0 comments
Please sign in to leave a comment.