This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Scheduled scan breaks for unknown reasons, Sophos logging failed

Hi,

we are in the process of moving scheduled scans to night hours.

Last night we had quite some machines which did not log the end of the scan as usual in the Scanjob.txt file:

Jobname: Nachts

Content of file Nachts.txt:

20120531 194237    Scan 'Nachts' gestartet.

Content of file SAV_20120531.txt :

20120531 194237    Scan 'Nachts' gestartet.
20120531 194950    Benutzer (NT-AUTORITÄT\SYSTEM) hat den On-Access-Scan auf diesem Computer abgebrochen.
20120531 195103    Die Erkennungsdatenversion 4.78G (Detection Engine 3.31.20) wird verwendet. Diese Version kann 3664173 Objekte erkennen.
20120531 195103    Benutzer (NT-AUTORITÄT\LOKALER DIENST) hat den On-Access-Scan auf diesem Computer gestartet.
20120531 195116    Die Erkennungsdatenversion 4.78G (Detection Engine 3.31.20) wird verwendet. Diese Version kann 3664173 Objekte erkennen.

and so on

When I go to such a machine I see that the scheduled scan does not run anymore, but why is the end of the scan not in the logs? This log entry does trigger the shutdown process of the machine here, and usually it works as expected.

:25441


This thread was automatically locked due to age.
  • Hello strubbel,

    strange that you didn't run into this before.  Just checked - the scan relies on savservice.exe. When the service is restarted the scan is silently stopped. Clearly the scan needs the service - but I'd have expected that it picks up again. Tried several times and once it looked like it did - can't tell as I was too surprised to think of all the details to check.

    Excuse me for writing bold red: It looks like a restart of savservice.exe silently kills any scan in progress

    Well. you might want to check with Support if this is indeed the case!

    Guess for the time being you can "script your way out" triggering the shutdown on the On-Access message (although I've just noticed that I've "lost" the Benutzer (NT AUTHORITY\SYSTEM) hat den On-Access-Scan auf diesem Computer abgebrochen. message when I restarted the service shortly after the scheduled scan had started. Still there's the problem of the aborted scan.

    Christian

    :25449
  • Hello Christian,

    thank you for the reply.

    I did not run into it just because I did not care for it ;)

    Now we have a job which reboots the clients, starts the sophos scan, and after it is finished, shuts them down.

    I found the problem because one morning lots of machines haven't been shut down.

    But I think it is a security problem - you excpect the machines have been scanned ok when the scan has been cancelled and not restarted, without any notice :-(

    I can't script around it because the script does not log the stopping of the job into the job's log file ;-(

    :25507
  • Hello strubbel,

    as I said, please contact Support to confirm this - as you rightly said, it's a security problem.

    It might be possible to trigger on the "On-Access started" message and treat it as "job ended". As another update is unlikely in the next few hours you could even repeat the procedure and start the scan anew. 

    Christian

    :25509
  • I did contact the Support.

    I got the suggestion to disable scanning of floppy disks and CD drives as well as disable scanning for Rootkist /Adware+ PUA .

    I think this was meant more like some kind of joke - what is a av scanner for?

    The best suggestion was to stop Sophos Autoupdate Service before the scan starts and restart it after the scan has finished..

    :25539
  • stop Sophos Autoupdate Service before the scan starts and restart it after the scan has finished..

    That's ridiculous - especially for a scheduled scan.

    Now it might not be as bad (or broken) as it seems. It looks like restarting the Sophos Anti-Virus service "reliably" kills the scan. While On-Access scanning is restarted on an IDE update this does not include the service. Obviously the service is restarted for version (release) updates - whether this might also happen "between" version updates I can't say. 

    Might be that you observed it when the clients upgraded from 10.0.4 to 10.0.5. Support shouldn't be so tight-lipped - they should know (or be able to find out) under which circumstances the service is restarted and how often (i.e. only at version updates or more frequent)  this occurs.

    As a workaround - I assume you have a "scanning window". You might consider setting a schedule for the update manager so that no software updates are downloaded during this time.

    Christian 

    :25545