Конечно интересно. Можно было бы поподробнее покопаться, но не хочется в данный момент тратить время.
Что в итоге я понял:
На сервере есть демон, который общается с GPIO через i2c.
Видимо на аппаратном уровне реализована собачка(watchdog), который в случае отсутствия периодического опроса демоном webjsond, осуществляет принудительный перезапуск контроллера, ведь что то пошло не так и надо перезагрузиться что бы демон webjsond запустился через демон webd.
Причем если запустить webjsond в интерактивном режиме, то что мы видим в евентах? Правильно. Пустые евенты.
А вот после того как мы убиваем второй процесс, то на нас с дикой скоростью вываливаются старые евенты. В моем случае вывалились евенты за три дня. Т.е. по факту - это скорее всего и есть причина сдвига указателя на крайний евент.
Т.е. видимо в процессе обычной работы, по какой то причине запустился второй экземпляр webjsond, и вот он и приводил к тому, что шли пустые евенты и потом вся история.
Это частично(а может и полностью) объясняет почему контроллер перезагружался если ему послать криво сформированный ответ на евент. Видимо webjsond не мог сериализовать ответ от сервера, и получал эксепшен. Умирал.... А вслед за ним перезапускался контроллер, что бы воскресить потерянного боевого товарища