Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • A arachni
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 125
    • Issues 125
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Arachni - Web Application Security Scanner Framework
  • arachni
  • Issues
  • #94
Closed
Open
Issue created Nov 01, 2011 by Administrator@rootContributor

Cygwin - zombie cleanup before reports saved

Created by: ghost

This is for the latest experimental branch (Arachni 0.4) on Cygwin.

There appears to be race condition that happens more often if the scanned site is relatively big with many issues (example: this always happen when I try a scan on "http://google-gruyere.appspot.com/start"):

  1. scan started
  2. after a while the scan is 100% done
  3. in the GUI you see (under scanner output): "connection lost"
  4. no reports are written and in the log file you only see:

webui started scheduler instance dispatched localhost:47035 scheduler instance_owner_assigned scheduler scan started webui zombie_cleanup

Missing is the normal:

report saved.

A quick fix is to increase the timing of the zombie scanning process (line 540 in server.rb), but this is no real solution and only minimizes the possibility that the race condition occurs.

I have tried to investigate where the issue comes from, but cannot trace the origin. Might have something to do with the way Cygwin handles forks and threads but I have to delve deeper. Other possibility is that the check in line 624 of server.rb might be wrong: if the framework in reality is 'busy', but there was a RPC exception, will 'busy' be set automatically to false? Haven't had the time to really investigate this.

Assignee
Assign to
Time tracking