Miscellaneous.

Junos BTLB binary without the BTLB_FLAG env set.

SRX-01 /kernel: exec_elf32_imgact: Running BTLB binary without the BTLB_FLAG env set
SRX-01 mgd[4433]: UI_CHILD_EXITED: Child exited: PID 4466, status 1, command '/usr/sbin/wmic'
SRX-01 mgd[4433]: UI_CHILD_EXITED: Child exited: PID 4467, status 1, command '/proc/1931/file'
SRX-01 mgd[4433]: UI_CHILD_EXITED: Child exited: PID 4471, status 1, command '/usr/sbin/webapid'

I have been observing the above log messages on SRX-550 every hour, and at first I was quite concerned, after some research, it turns out to be nothing to worry about.
The message is produced every time you do a show version detail
What happens is that a new forwarding process is started up in parallel to the one that is already running (and doing the forwarding). The new process is started without a flag being set, and is only running for long enough to get the binary version from it and then shuts down.
The reason it happened every hour for me is because; we have Rancid collecting configuration backup from the device every hour and part of the Rancid script runs the show version detail

Don't be confused with traceroute behaviour.

Over the course of the years I have observed; many times; traceroute failure even when the device is up. Sometimes traceroute from a customer PC to some destination does not work, and It would work with another PC when connected to the same network. What I failed to ask the customer is what OS are they running on their computers. See we often think traceroute is just ICMP messages but this is not always the case.
Traceroutes on Windows machines uses ICMP Echo Request while on Linux and Unix machines, traceroute uses UDP packets. This means if there device is discarding UDP in the network path and you are performing traceroute from a linux machine packets the traceoute response will not be sent back to the source, and you would see the same effect as if the node was not reachable. Similarly if you traceroute from Windows PC and somefirewall in the path is blocking ICMP trace would fail. For extensive details on this behaviour check out this post