My vague notion was that if you were using a centralised logging mechanism that added time stamps upon reciept, there might be some buffering going on.

As described, it is hard to conceive of any circumstance that could result in the child perl being able to write after the parent cmd had completed. Nor even of what might cause the parent cmd to end before the child perl completed.

Hence, looking for some reason why the recorded time stamps might be incorrect.

A very (very) remote possibility, if you have NTP synchronisation set up, is that the time was synchronised between the child writing the file and printing its log message; and the grandparent detecting the completion of the parent and writing its log file; and the system's clock had been running 8 seconds fast prior to syncing. Unlikely, but if the time frame fits with the scheduled sync time on the machine...

Beyond that, if the problem occurs sufficiently frequently to make it worth your while fixing the problem, rather than adding some workaround like sleeping for 10 seconds if the file isn't immediately available, then I'd look to setting up the Performance Monitoring tool to track processes and IO and see if that sheds any light once the problem reoccurs. Be very selective in what you choose to monitor, those Performance logs can get very large, very quickly.