Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

daily cron runs overlap #373

Open
jnorell opened this issue Nov 11, 2020 · 1 comment · May be fixed by #374
Open

daily cron runs overlap #373

jnorell opened this issue Nov 11, 2020 · 1 comment · May be fixed by #374

Comments

@jnorell
Copy link
Contributor

jnorell commented Nov 11, 2020

The scan from the daily cron job should use a lock file so only one instance runs at a time.

We have one web server with enough files being scanned by the daily cron run that it sometimes doesn't complete within 24 hours, and the next day's cron job kicks off and starts another overlapping scan job - from there, things just go downhill, as the surely won't complete in a day, etc. ... after a while it'll be sluggish and I'll find 4 or 5 simulatneous scans running.
@jnorell
Copy link
Contributor Author

jnorell commented Nov 11, 2020

As the daily maldet scan runs in the background (-b), the cronjob as a whole can't just use a lock file, but I did test running the maldet scan without -b in a subshell, and have the subshell check/create/remove the lockfile, which worked. There may be more elegant solutions.

jnorell added a commit to jnorell/linux-malware-detect that referenced this issue Nov 11, 2020
@jnorell
daily maldet scan uses lock file
15b9405 
fixes rfxn#373
@jnorell jnorell linked a pull request Nov 11, 2020 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

daily maldet scan uses lock file jnorell/linux-malware-detect
1 participant
@jnorell