Creating a feedback file ("Pause running McAfee Web Gateway to create a backtrace")

[GrigorySalnikov]

Hello Community!

We're dealing with some synchronization issues and are requested by the technical support to create a feedback file. As per this KB article, the process seems very simple and straightforward BUT

what does exactly "Pause running McAfee Web Gateway to create a backtrace" means? Are the existing user sessions interrupted? Can users create new sessions? What impact will this checkbox have on our production environment?

We're told that the backtrace file can be very useful for troubleshooting but we're not sure whether we should collect it (our production environment is very critical).

Any help will be appreciated.

[mkutrieba · Accepted solution]

Hello,

I have got this information in the past from another colleague:
"Pausing the running MWG to perform a backtrace will not stop the service.
Pausing the service simply means that MWG will attempt to gather information about the running MWG services."

I can confirm, that this will NOT stop any service and that "live" information about current running/processed connections and scans is gathered.

We request feedback files everyday from every single customer and I have never heard from any, that creating a feedback file lead to any performance related errors. It occurred that feedback file generation itself failed for various reasons, but even this had no affect on user traffic.

It is important for us (support) to have all detailed information, especially when troubleshooting performance related cases because then we can check what the individual processes like mwg-core are currently processing, how long they are running etc. With backtrace we can also check what all the threads are doing, if they are hanging and where etc.

[GrigorySalnikov]

Thank you so much!

Now we can relax and collect the detailed feedback file 🙂

Have a nice day!

[fw_mon · Accepted solution]

"Pause running McAfee Web Gateway to create a backtrace" will call "gstack $pid" for each LWP (lightweight thread), which causes small delay (about ~2sec, see wait4 call below in the strace output) of the thread execution. But because gstack runs sequentially it is very improbable that any user can notice any delay. 

# strace -r gstack 3254
...
     0.000039 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 😎 = 0
     0.000051 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 😎 = 0
     0.000033 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 😎 = 0
     0.000066 rt_sigaction(SIGINT, {0x43db60, [], SA_RESTORER, 0x7f826c9363f0}, {SIG_DFL, [], SA_RESTORER, 0x7f826c9363f0}, 😎 = 0
     0.000033 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 696
     1.875525 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 697
     0.000294 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 😎 = 0
     0.000158 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f826c9363f0}, {0x43db60, [], SA_RESTORER, 0x7f826c9363f0}, 😎 = 0
...
     0.000319 exit_group(0)             = ?
     0.000182 +++ exited with 0 +++

[GrigorySalnikov]

Wow, thank you, kind sir.

Never expected so deeply detailed technical explanation. Hope my question and your comprehensive answers will help someone else. Because I couldn't find any information.

Good luck!