EG>>> А у bhyve есть стартовый скрипт rcNG? VS>> Есть. EG>>> Для теста неплохо бы прописать EG>>> зависимость у syncthing (кстати, что это?) VS>> net/syncthing EG>>> от bhyve: EG>>> REQUIRES: bhyve EG>>> Тогда rc.shutdown гасить их будет в обратном порядке и остановит EG>>> syncthing до гашения bhyve. Если паника уйдет, мы на верном EG>>> пути. VS>> Hе понял, при чем тут syncthing вообще, и почему ты о нем VS>> заговорил. Я могу его руками погасить заранее перед shutdown и VS>> проверить наличие паники, но почему именно syncthing?
EG> Из твоей же паники:
EG> current process = 2140 (syncthing)
EG> Именно останов syncthing (системный вызов exit1) приводит к закрытию EG> дескрипторов (closef) сокетов (udp6_detach) и отключению умирающего EG> процесса от мультикаст-группы (in6_mc_leave), во время которого EG> mld_change_state пытается залочить уже разрушенный другим ядерным EG> тредом ifp - вероятно, от bridge1.
Оказывается, "killall syncthing" само по себе (не при shutdown, а просто на работающей системе) приводит к GPF и kernel panic. Я отразил это в PR 228412.
Хотел проверить: убить заранее syncthing и сделать shutdown без него: будет ли паника. А оно вот как оказалось.
И кстати, syncthing запускается у меня не из rcNG, а тупо из-под пользователя, из крона на @reboot.
