The EXTTRIG MEDM screen was apparently not working correctly on first glance. The last query time was updating correctly, but the last event was from Nov 6th and there have been many events since that time.

Upon investigation, it turns out that the system is behaving correctly. Here is the sequence:

the epics channels exttrig uses are served by the h1calcs model. This runs on h1oaf0, which has been restarted many time over the past week. Each time the h1calcs model is restarted, two things happen:

1. the EXTTRIG epics channels are restored from the safe.snap file, which has the Nov 6th event data recorded
2. the EXTTRIG script crashes (due to lost connection with its EPICS channels) and is restarted by monit. On restart, if no events have occured in the past 10 hours, the event info is not updated and the Nov 6th data stands.

For the record, here is the startup sequence of the code on h1fescript0:

process is controlled by monit. Its file is /etc/monit/conf.d/monit_ext_alert.  It monitors a process whose PID is stored in the file /var/log/ext_alert/ext_alert.pid.

If the process needs to be started/restarted, monit executes (as root) the file /etc/init.d/ext_alert. This in turn, using the start-stop-daemon runs the script /home/exttrig/run_ext_alert.sh, and this runs the script /opt/rtcds/userapps/release/cal/common/scripts/ext_alert.py with the appropriate arguments.

We are investigating this morning's Tuesday test events were not  recorded. These are T-events in gracedb with a label of H1OPS. The run_ext_alert.sh script was not calling ext_alert.py with the '--test' argument to query for test events. We turned on the gracedb-query of test events in /home/exttrig/run_ext_alert.sh and got this morning's test event on startup. Duncan pointed out that there are many non-ops test events per day so this will generate many false positives.