I read in troubleshooting guide that If TIM crashes, Timwatchdog will restart it.But I cross-verified in watchdoglog and found below.
--- tim exited with status 0 after 20 seconds at Tue Aug 18 23:16:27 2015
Removing core file "core.20188"
+++ Running tim at Tue Aug 18 23:16:30 2015
This looks like tim exited gracefully which means TIM not crashed. But I see above log messages continuosly for 18 minutes and also "TIM restarted by administrator" messages also continuosly in CEM events page. These messages does not seem like TIM was restarted manually.
This resembles TIM restarted by watchdog. But How do we know exactly whether TIM crashed and if it was restartd by watch dog or not?
A TIM automatic restart can be due to load, traffic quality,plugins and other factors. Along with the core file, there should be a hs-err file. That may give a clue. The TIM watchdog log will list if memory was exceeded.
Can you give me some more detailed information please?
hub: hubmanager: timworker #0 process 12783 exited with signal 11
hub: hubmanager: write thread for timworker #0 exiting
**ERROR: hub: hubmanager: exiting because timworker #0 exited
I found this error. What this means? How can I interpret signal 11?
Ok. I get it. Signal 11 is segmentation fault in linux means that the program accessed a memory location that was not assigned
But can this error enough to crash TIM?
Signal 11 in Unix land implies a segmentation fault, i.e process accessing some unintended portion of memory and subsequently crashing.
As Hal outlined earlier in this scenario a "core.*" and\or "hs_err*.log" would be generated in the TIM folder which then needs to be analyzed further.
Root cause can be anything corrupted data, bad regex in TIM matching definition or even a TIM bug that might have been addressed in later releases, this involves deeper analysis and review so kindly open up a support issue and upload following so we can help:
-Zip of TIM logs folder
-TIM version details
Further to Hal & Kulbir's advice TIM "signal 11" core dumps have been previously reported where the root cause was Flex application packets.
There is a fix in APM 9.7 - see "Defect 328338 - TIM stability issue with FLEX traffic" on this 9.7 wiki page: Customer Experience Manager Fixed Issues
Do you have Flex traffic & what version of TIM are you using?
The TIM Flex plugin is enabled by default so you can also test if disabling has any effect on TIM process stability. This KB has details on how to do that: Troubleshooting TIM Settings Issues
Hope this helps