As title says, LOCKLOSS guardian hung up during 16:22 - 18:56.
It's already resumed and missing lockloss events were reproduced.

-----
LOCKLOSS guardian depends on LSC_LOCK.py in order to get a relation ship between STATE_N and STATE_S. Only STATE_N is DAQ-ed and we need to reconstruct state name in which LSC_LOCK stayed just before lockloss only from DAQ-ed channels.

Today LSC_LOCK.py was modified during the commissioning activities and when some user code errors existed lockloss happened. LOCKLOSS guardian loads LSC_LOCK.py when lockloss occurs. So we don't need to take care about a change in state list of LSC_LOCK. On the other hand, it can be stopped due to user code errors in LSC_LOCK.py. This issue occurs only when the lockloss occurs during the modification of LSC_LOCK.py. So it's an unfortunate accident. We can remove this issue completely by removing the dependency from LOCKLOSS guardian to LSC_LOCK.py. But in this case we need to update the state list manually when LSC_LOCK.py is modified by someone.

I think former one is better from the view point of efforts to manage the LOCKLOSS guardian for now. Recovering from this issue can be done by reload LOCKLOSS guardian after removing user code errors in LSC_LOCK.py. If you faced a lockloss during injection of bugs to LSC_LOCK.py, please remember the LOCKLOSS guardain.