The UPDD watchdog service is a daemon process looking for specific software or hardware failures that may cause the UPDD software (and therefore touch) to stop responding.
Whilst UPDD is written to be robust in a wide variety of target environments there are occasionally unusual situations where the software needs to be reset in some way.
The watchdog service provides an extensible implementation in support of this.
There are two main aspects of the watchdog service; watchdog events and a recovery script.
Watchdog events
A watchdog event is a symbol that identifies a predefined error case and reflect the cases we have observed thus far and will be extended as and when required.
The following events are currently defined. This list will be added to as the need arises.
| Event |
Description |
| usbenum |
The USB enumeration process has stalled. Typically this occurs when a controller does not respond and the usb stack becomes frozen. |
| usberror |
A USB open operation has failed as seen in our diagnostics log:
|
| maxreaderrors |
A USB read operation has failed repeatedly with no successful reads in between. This sometimes occurs when a device enters a bad state, for example after an EMF event.
|
By default no events are monitored as in our experience most systems do not experience lockup issues that need recovery and therefore it is unnecessary to run the monitoring service. In environments that do warrant/require this service then a UPDD setting 'watchdog.events' defines which events are active and are defined in a comma separated list.
The driver must also include the watchdog recovery script. This script is used to forcibly restart updd.
(Technical note for TB staff - Bundle must include the watchdog_recover customisation to add the script to the installer)
This setting can be preset in a UPDD software bundle or set using the UPDD Command Line Interface
In this Windows example two events are set active using the upddutils command:
This feature will be active the next time the driver starts after changing this setting.
Recovery script
The recovery script is called whenever a watchdog event is triggered, i.e. the related 'error' scenario occurs.
This will be in one of the following locations:
| Operating system |
Location |
| Windows |
<upddinstallfolder>\recover.bat |
| Mac |
/Library/Application Support/UPDD/recover.sh |
| Linux |
/opt/updd/recover.sh |
The triggered event is passed as an argument to the recover script.
E.g. If usbenum occurs on a Mac system:
/Library/Application Support/UPDD/recover.sh usbenum
is executed.
The recover script is executed with elevated privileges.
The recover script will contain commands used to recover from the detected error, such as restarting the failed component or utilise Windows DevCon to clear a device error state in the case of a USB communication error under Windows.
The main aim of the watchdog service is to identify an error scenario and call a predefined script that will contain the commands needed to address the issue. The script commands will need to be assessed on a case by case basis.
Advance Windows batch file use
It could be considered that invoking .bat files rather than some alternative Windows scripting languages does not cater for advanced scripting options but .bat files are easy to use and do cater for most scripting requirements including the ability to launch a script in a more advanced scripting language if required.