Closed Aldaviva closed 3 years ago
Service startup will now proceed without blocking on deleting existing firewall rules, which will happen asynchronously. New ban creation will wait for this initial deletion phase to be over before adding new rules to the firewall.
While the service is starting, it deletes existing firewall rules that it previously created (filtered by Group; it doesn't delete any other rules created by other tools, Windows, or the user). It does this because otherwise the rules would never be deleted when the corresponding ban expired.
This runs in the constructor of the
BanManagerImpl
. TheWindowsService.Start()
method depends on this, so it blocks that method from finishing until all rules have been deleted. If there were a lot of rules to delete (there can be hundreds), this makes that method take a while to run. This results in the service taking a long time to start, as seen by how long it takes fornet start Fail2Ban4Win
to return, or for the progress bar to disappear when starting it fromservices.msc
.To solve this, we can start a new asynchronous
Task
in the constructor instead of running the blocking calls synchronously, so the constructor can finish and the rule deletion will finish at some point in the future, and the service can start and begin processing Event Log records.To avoid overlap with rule creation, the rule deletion Task can signal a
ManualResetEventSlim
semaphore object or something, and rule creation canWaitOne()
on that semaphore, which will only block if the initial deletion hasn't completed.