In MX10003 we observed eventd core dumped twice, after upgrade, but without any scripts or event-options running.

root@JTAC-re0> show system core-dumps no-forwarding

/var/crash/*core*: No such file or directory

-rw-rw---- 1 root wheel   1157873 Jun 1 22:54 /var/tmp/eventd.core-tarball.0.tgz

-rw-rw---- 1 root wheel   1142841 Jun 11 15:41 /var/tmp/eventd.core-tarball.1.tgz

The BT from core is matching PR1751282.

After upgrading of the device, eventd is checking for interface to bind. It is trying for 1000 times to bind but looks to be interface is not up during that time so, bind attempt failed in 1001 times.

So it is continuously loops over recursive function call "check_interface_status" in bt, at some point of time it may have lead to core.

Having management-instance in config do have an impact here.

The bind APIs in core file is having syslog call also. Upon checking config, they are using source address as lo0 for syslog.

When we enable management-instance & the lo0 is not under mgmt_junos RI, syslogs itself might not get forwarded.

Once lo0 under mgmt_junos RI, developer mentioned, we may not see core at all for eventd. The core generation is a rare event in this scenario & hence not seen in all devices.

For syslog, it uses management-instace, once configured & hence eventd bind uses it.

This behaviour is modified from 24 rel, via RLI 56838 (syslog to be sent out from inet.0 while management-instance configured). 

So only options are to remove management-instance or ensure source is under mgmt_junos.