fix(omsentinel): multiple fixes and cleanup - #26
Conversation
There was a problem hiding this comment.
isn't there a control problem with the number of bytes received? and the fact that contents may not be NULL terminated?
There was a problem hiding this comment.
this value should be saved along authReply, and used for all manipulations of the variable (especially in loggers and curlAuth())
| curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &http_code); | ||
| if (http_code != 200) | ||
| { | ||
| dbgprintf("omsentinel: http_reply_code=%ld \n", http_code); |
There was a problem hiding this comment.
| dbgprintf("omsentinel: http_reply_code=%ld \n", http_code); | |
| LogError(0, RS_RET_SUSPENDED, "omsentinel[curlAuth]: http_reply_code=%ld", http_code); |
| res = curl_easy_perform(curl); | ||
| if (res != CURLE_OK) | ||
| { | ||
| LogError(0, RS_RET_ERR, "curl: error: %s\n", curl_easy_strerror(res)); |
There was a problem hiding this comment.
| LogError(0, RS_RET_ERR, "curl: error: %s\n", curl_easy_strerror(res)); | |
| LogError(0, RS_RET_SUSPENDED, "omsentinel[curlAuth]: error: %s", curl_easy_strerror(res)); |
| if(!(pData->token = (uchar *)strdup(tokenStr))) | ||
| { | ||
| LogError(0, RS_RET_OUT_OF_MEMORY, | ||
| "omsentinel: could not allocate Bearer token \n"); |
There was a problem hiding this comment.
| "omsentinel[curlAuth]: could not allocate Bearer token"); |
| ABORT_FINALIZE(RS_RET_SUSPENDED); | ||
| } | ||
| json_object_put(parsed_json); | ||
| } |
There was a problem hiding this comment.
| } | |
| } | |
| else | |
| { | |
| LogError(0, RS_RET_SUSPENDED, "omsentinel[curlAuth]: Could not decode a valid JSON in reply"); | |
| ABORT_FINALIZE(RS_RET_SUSPENDED); | |
| } |
| } | ||
| else | ||
| { | ||
| LogError(0, RS_RET_OUT_OF_MEMORY, "omsentinel: could not allocate http response \n"); |
There was a problem hiding this comment.
| LogError(0, RS_RET_OUT_OF_MEMORY, "omsentinel[curlAuth]: could not allocate http response"); |
| // httpHeader | ||
| if (asprintf((char **)&pData->httpHeader, (char *)pData->authorizationHeader, pData->token) < 0) | ||
| { | ||
| LogError(0, RS_RET_OUT_OF_MEMORY, "omsentinel: cannot allocate memory for http header\n"); |
There was a problem hiding this comment.
| LogError(0, RS_RET_OUT_OF_MEMORY, "omsentinel[curlAuth]: cannot allocate memory for http header"); |
| if (pData->httpHeader) | ||
| { | ||
| free(pData->httpHeader); | ||
| } |
There was a problem hiding this comment.
Those variables are relative to the instance, so they can be accessed by several workers at once
I believe:
- the values should be protected by a mutex
- or the values could be relative to the worker (meaning = 1 token per worker = more authentication requests! So maybe not advisable)
|
|
||
| if (pData->token && pData->dce && pData->dcr && pData->stream_name) | ||
| // Before building batch check/regenerate auths | ||
| CHKiRet(initAuth(pWrkrData)); |
There was a problem hiding this comment.
after reflecting on the code, it seems there is a deep misunderstanding (or misuse) of transactions and the doAction macro.
- I believe
doActionshould tell rsyslog how to handle the current transaction (send, keep, drop, etc... see RS_RET_DEFER_COMMIT in rsyslog.h) - Handling of current authentication could be moved to the
endTransactiontransaction (if transactions were correctly used), whensubmitBatch()would be used (and it would be the only call to the function)
Summary
This PR introduces several fixes and improvements to the omsentinel module,
focusing on memory management, resource handling, and overall stability. It also improves the clarity of error logs.
In this PR, each commit targets a specific fix.