rsyslog/rsyslog
1
0
Fork 0
mirror of https://github.com/rsyslog/rsyslog.git synced 2025-12-20 02:40:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

bugfix: ompipe did emit many suspension messages for /dev/xconsole

Browse Source 
(hopefully now) closes: https://github.com/rsyslog/rsyslog/issues/35
When it was present, but nobody reading from it. The problem
is the way the rsyslog v7 engine tries to resolve failures in outputs.
It does some retries, and along those lines some state information gets
lost and it is close to impossible to retain it. However, the actual
root problem is that ompipe does not reliably detect if it is able to
recover. The problem here is that it actually does not know this
before it does an actual write. These two things together mess up the
logic that suppresses invalid resumption/suspension messages
(actually, the plugin switches state really that often).
Nevertheless, the prime problem with /dev/xconsole (and probably
most other pipes as well) is that it gets full. So I have now added
code that checks, during resume processing, if the pipe is writable.
If it is not, resume is deferred. That should address the case.
This commit is contained in:
Rainer Gerhards 2014-03-25 15:12:14 +01:00
parent 8d19530c22
commit a79b07fcd2
2 changed files with 35 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
ChangeLog
View File

@ -5,6 +5,21 @@ Version 7.6.3 [v7.6-stable] 2014-03-??
- support for librelp 1.2.5
Support new return states of librelp 1.2.5 to emit better error messages
For obvious reasons, librelp 1.2.5 is now required.
- bugfix: ompipe did emit many suspension messages for /dev/xconsole
(hopefully now) closes: https://github.com/rsyslog/rsyslog/issues/35
When it was present, but nobody reading from it. The problem
is the way the rsyslog v7 engine tries to resolve failures in outputs.
It does some retries, and along those lines some state information gets
lost and it is close to impossible to retain it. However, the actual
root problem is that ompipe does not reliably detect if it is able to
recover. The problem here is that it actually does not know this
before it does an actual write. These two things together mess up the
logic that suppresses invalid resumption/suspension messages
(actually, the plugin switches state really that often).
Nevertheless, the prime problem with /dev/xconsole (and probably
most other pipes as well) is that it gets full. So I have now added
code that checks, during resume processing, if the pipe is writable.
If it is not, resume is deferred. That should address the case.
---------------------------------------------------------------------------
Version 7.6.2 [v7.6-stable] 2014-03-17
- support for librelp 1.2.4

23
tools/ompipe.c
View File

@ -12,7 +12,7 @@
* NOTE: read comments in module-template.h to understand how this pipe
* works!
*
* Copyright 2007-2012 Rainer Gerhards and Adiscon GmbH.
* Copyright 2007-2014 Rainer Gerhards and Adiscon GmbH.
*
* This file is part of rsyslog.
*
@ -288,18 +288,35 @@ ENDfreeInstance
BEGINtryResume
fd_set wrds;
struct timeval tv;
int ready;
CODESTARTtryResume
if(pData->fd == -1) {
rsRetVal iRetLocal;
iRetLocal = preparePipe(pData);
if((iRetLocal != RS_RET_OK) || (pData->fd == -1))
iRet = RS_RET_SUSPENDED;
ABORT_FINALIZE(RS_RET_SUSPENDED);
} else {
/* we can reach this if the pipe is full, so we need
* to check if we can write again. /dev/xconsole is the
* ugly example of why this is necessary.
*/
FD_ZERO(&wrds);
FD_SET(pData->fd, &wrds);
tv.tv_sec = 0;
tv.tv_usec = 0;
ready = select(pData->fd+1, NULL, &wrds, NULL, &tv);
DBGPRINTF("ompipe: tryResume: ready to write fd %d: %d\n", ready);
if(ready != 1)
ABORT_FINALIZE(RS_RET_SUSPENDED);
}
finalize_it:
ENDtryResume
BEGINdoAction
CODESTARTdoAction
DBGPRINTF(" (%s)\n", pData->pipe);
DBGPRINTF("ompipe writing to: %s\n", pData->pipe);
iRet = writePipe(ppString, pData);
ENDdoAction