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.
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
CLAM-2159: fix clamonacc --log=FILE bug #751
Conversation
|
It looks like the core of this fix is to initialize logging to occur before ctx->fan_fd = fanotify_init(...One minor related thing that is probably not a functional issue: In if (g_ctx) {
if (g_ctx->fan_fd) {
close(g_ctx->fan_fd);
}
- g_ctx->fan_fd = 0;
+ g_ctx->fan_fd = -1;
}And in struct onas_context *onas_init_context(void)
{
struct onas_context *ctx = (struct onas_context *)cli_malloc(sizeof(struct onas_context));
if (NULL == ctx) {
return NULL;
}
memset(ctx, 0, sizeof(struct onas_context));
+ ctx->fan_fd = -1;
+
return ctx;
}I don't think these are functional issues but I'm mentioning them because I suspect the race condition has something to do with a race condition between the logging fd and Anyways,... Next up I'll try testing a bit. |
|
I have bad news, I was able to reproduce the issue on both the Here is the randomly named file created in my current (install) directory: To reproduce the issue, I did the following:
It took quite a number of start/stops but eventually it resulted in the randomlly named file in my current directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to set review status to 'request changes'.
Not sure what change is required -- Outside of the two small things with the ctx->fan_fd, I haven't found any leads on the source of the bug.
A race condition existed where clamonacc would call logg and attempt to write to a logfile either before the logg interface had been initialized or after it had been cleaned up. This happens due to logg calls at cleanup during asynchronous thread shutdowns, and during startup when watching directories with ongoing event triggers. This resulted in new files with garbage-filled names being created and written to under the initial process' runtime path. Changes: Move logg setup to start of clamonacc.c main() Change all raceable calls to logg to mprintf instead
|
@m-sola I was able to trigger it again: The file content in this case was I suspect it may have happened with I did multiple Ctrl-C's in a row, because Edit: if that turns out to be true that the outstanding issue only occurs in this edge case where i have to force-kill with extra ctrl-c's, then I won't worry about it and we should just merge this as-is. I'll let you know what I find. I will try testing some more where I don't do that with lots of start-stops. |
|
Yeah I was able to reproduce the same one by sending What that looked like: ❯ sudo ./sbin/clamonacc --log=$HOME/clamonacc.log -F --fdpass
--------------------------------------
ClamInotif: watching '/home/micasnyd/' (and all sub-directories)
ClamInotif: extra scanning on inotify events enabled
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-aspack.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-fsg.exe: Clamav.Test.File-6 FOUND
^CClamInotif: stopped # <--- first Ctrl-C when FOUND's start coming back
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-mew.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-fsg.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-nsis.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-aspack.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-mew.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-petite.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-fsg.exe: Clamav.Test.File-6 FOUND
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam-upack.exe: Clamav.Test.File-6 FOUND
^CClamonacc: stopped # <--- second Ctrl-C because clamonacc wasn't stopping.
# This is the moment when the randomly named file gets written.
/home/micasnyd/tmp/build/unit_tests/input/clamav_hdb_scanfiles/clam_ISmsi_ext.exe: Clamav.Test.File-6 FOUND
ERROR: ClamClient: Connection to clamd failed, Couldn't connect to server.
^CClamonacc: stopped # <--- third Ctrl-C because clamonacc still hadn't stopped.
fish: 'sudo ./sbin/clamonacc --log=$HO…' terminated by signal SIGSEGV (Address boundary error)The resulting file: The issue of not being able to kill |
|
Note: I wasn't able to reproduce the random-named-log bug when doing clean start/stops. Only when doing the extra Ctrl-C's to kill it ... violently. |
Moves logg setup to start of clamonacc.c main()
Changes all calls to logg which may occure before init to mprintf
Addresses #168