On 2013-06-27 20:01, Matt wrote:
I'm
attaching a snippet of my log. About 100 lines past the start,
where you see a smattering of error messages, you then see a large
block of them while the Sniffer service is restarting, and then
after that no errors at
Pete,
I'm near positive that it's not system resources that are causing
Sniffer to not be able to _access the files_. I believe these errors
are a symptom and not the cause.
You have to keep in mind that on the messages that don't throw errors,
they were taking 30-90 seconds to scan, but
Matt:
I mentioned in a previous post that we had experienced something similar at
about that time and resolved it a day or so later by re-installing sniffer
when service restarts, reboots and some basic troubleshooting did not give
us the results we needed. At this point that still seems to have
I'll certainly look more closely next time. Hopefully I'll be migrated
before this happens again :)
Matt
On 6/28/2013 1:44 PM, Darin Cox wrote:
How about running performance monitor to watch disk I/O, mem, cpu,
page file, etc. over time in the hopes of catching one of the events?
Darin.
Eric,
I'm guessing based on what you were seeing, that it was unrelated to
what I was seeing. Sniffer never actually died, it just got over 100
times slower, and 1/8th of the time it timed out. This never happened
before 5/22, and this same server has been there for years, and the same
Matt:
Coincidentally (I hope) this happened to us on the 22nd also. It did not
stop working completely although we didn't get the throughput you did. We
also saw the messages indicating it was not able to open the file. Pretty
much the same message as in your first post and not one I've seen
I should add that Sniffer has been pretty much trouble free for us. We have
been using it since before the ARM research days (10+ years as a guess).
One of the specialized clients we host for goes through a cycle every few
years where they are very publically visible and there are a number of
I just looked through my history of the SNFclient.exe.err log and I was
a bit off. There were two small occurrences before 5/22, and both were
so small they were without a doubt unnoticeable. Here's my history
since installation on 4/10/2012 with the number of occurrences of Could
Not
On 2013-06-28 16:49, Matt wrote:
maybe the updates will cause a service restart/reset?
Rulebase updates (all updates in fact) happen without restarting
anything. SNF simply loads the new configuration, validates it, uses it
for new scans, and when all of the old scans are complete it drops
