| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
it permits to specifiy if asynchronous writing should be done or not
|
|
|
|
|
|
|
| |
Further testing turned out that the rsyslog core works correctly and
this fix is not needed. The concurrency we saw was actually caused by
other actions (even processes) during directory creation. See commit
9e5b31fc44136dbcc1e443cfe7714e9daf97d844 for further details.
|
|
|
|
|
|
|
|
|
| |
This bug was triggered by an open failure. The the cache was full and
a new entry needed to be placed inside it, a victim for eviction was
selected. That victim was freed, then the open of the new file tried. If
the open failed, the victim entry was still freed, and the function
exited. However, on next invocation and cache search, the victim entry
was used as if it were populated, most probably resulting in a segfault.
|
|
|
|
|
|
| |
The old code looks a bit "strange", though not necessarily incorrect.
The new code looks correct and is probably less irritating during bug
hunting.
|
|
|
|
|
|
|
| |
when dynaCache is enabled, the cache is full, a new entry needs to
be allocated, thus the LRU discarded, then a new entry is opend and that
fails. In that case, it looks like the discarded stream may be reused
improperly (based on code analysis, test case and confirmation pending)
|
|
|
|
| |
This is what caused the new test to fail...
|
|
|
|
|
|
|
|
|
|
|
|
| |
file instance
In theory, the rsyslog core should never call in parallel into an output
module for the same instance. However, it looks like this seems to happen
under (strange?) circumstances. I have now enhanced omfile so that it guards
itself against being called in parallel on the same instance data. This is
done to help troubleshooting and may stay as an interim solution if it
proves to solve an anomaly we see in at least one installation (to trigger
this problem, an extremely large traffic volume is needed).
|
|
|
|
|
|
|
|
| |
The previous fix fixed an issue with on/off bying used in the exact wrong
semantic. It corrected the situation, but failed to fix one spot where the
wrong semantics were used. This is done with this commit.
Note that this is NOT a bug seen in any released version.
|
|
|
|
| |
(this is primarily meant as a debug aid)
|
|
|
|
|
|
|
|
|
|
| |
When a write error occured in stream.c, variable iWritten had the error
code but this was handled as if it were the actual number of bytes
written. That was used in pointer arithmetic later on, and thus could
lead to all sorts of problems. However, this could only happen if the
error was EINTR or the file in question was a tty. All other cases were
handled properly. Now, iWritten is reset to zero in such cases, resulting
in proper retries.
|
|
|
|
|
| |
required because due to bug the default was actually different than
specified (or better said: spec was inconsistent in doc as well).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- bugfix: potential segfault in omfile when a dynafile open failed
In that case, a partial cache entry was written, and some internal
pointers (iCurrElt) not correctly updated. In the next iteration, that
could lead to a segfault, especially if iCurrElt then points to the
then-partial record. Not very likely, but could happen in practice.
- bugfix (theoretical): potential segfault in omfile under low memory
condition. This is only a theoretical bug, because it would only
happen when strdup() fails to allocate memory - which is highly
unlikely and will probably lead to all other sorts of errors.
|
|
|
|
|
|
|
|
|
| |
This was not honored by the new ompipe module, because it is a local
file directive (it was applied to pipes as a side-effect of using the
same module for pipes and files...). I now made this a global, so that
semantics are the same as previously. Not really nice, but probably
the best thing to do in the current situation (everything else would
involve much more overhead --- leave that for the new config system).
|
| |
|
|
|
|
|
|
|
| |
... based on old omfile. Michael Biebl reported that xconsole seems
to have some issues with the new pipe code, so it was best to use
the old code for pipes. The optimizations were done to speed up file
access, so it doesn't really matter pipes do not receive them.
|
|
|
|
| |
Thanks to Michael Biebl for reporting this bug.
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | | |
default thus was random (but most often "on")
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- bugfix: invalid error message issued if $inlcudeConfig was on an empty
set of files (e.g. *.conf, where none such files existed)
thanks to Michael Biebl for reporting this bug
- bugfix: when run in foreground (but not in debug mode), a
debug message ("DoDie called") was emitted at shutdown. Removed.
thanks to Michael Biebl for reporting this bug
- bugfix: some garbagge was emitted to stderr on shutdown. This
garbage consisted of file names, which were written during
startup (key point: not a pointer error)
thanks to Michael Biebl for reporting this bug
- bugfix: startup and shutdown message were emitted to stdout
thanks to Michael Biebl for reporting this bug
|
| | |
| | |
| | |
| | | |
this was a regression from the omfile rewrite in 4.5.0
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This resulted in wrong values. The most prominent victim was the
directory creation mode, which was set to zero in some cases. For
details, see related blog post:
http://blog.gerhards.net/2009/10/another-note-on-hard-to-find-bugs.html
This replaces the improper bugfix from two commits ago with a proper one.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
one-time write to the mode, then all works. However, if no such write
is done, the variable always remains zero. I have used the memory
debugger as well as shuffled the code around and used guard variables
nothing changed. The problem always moved with the changes I did. So
I now consider the one-time write a usable work-around, because it
definitely fixes the issue even though it does not explain why it
happens.
|
| | |
| | |
| | |
| | |
| | | |
... seems to work on quick testing, but needs a far more testing
and improvement. Good milestone commit.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This is the first shot at this functionality. Currently, we run off a fixed
counter in the rsyslogd mainloop, which needs to be restructured. But this
code works, so it is a good time for a commit.
|
| | |
| | |
| | |
| | | |
plus some cleanup...
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... by moving code to stream.c. Thanks to the new design, new cases are
not really needed, resulting in cleaner code.
I also did a cleanup of header file usage as a side-activity.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
... restoring missing functionality after the restructuring of imfile. As
a side-effect, this also lays the foundation for even more reliable queue
engine operations (but this is not yet done).
|
| | |
| | |
| | |
| | |
| | | |
now cleand up omfile and straighted out some things. The only commented-out
code left is code that must be moved/merged to the stream class, my next target.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
now only stream class is utilized. ttys, pipes and outchannel functionality
is currently disabled. But the testbench worked again. Cleanup needed, will
do this with next commit (it may break things and I like to have this
milestone here).
|
| | | |
|
| | |
| | |
| | |
| | | |
now some basic operations are carried out via the stream class.
|
| | |
| | |
| | |
| | |
| | |
| | | |
... and also made it callable via an rsyslog interface rather then
relying on the OS loader (important if we go for using it inside
loadbale modules, which we soon possible will)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The former maximum of 10,000 really made no sense, even 1,000 is very high,
but we like to keep the user in control ;)).
Also, some general cleanup was done.
|
| | |
| | |
| | |
| | | |
so they can now be processed with the "regular" gzip tools
|
|/ /
| |
| |
| |
| |
| | |
This DOES NOT work sufficiently well, I just wanted to verify that
zip writing is possible and files are readable. Will be refined
soon.
|
|\| |
|
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| |
| |
| |
| |
| |
| |
| |
| | |
to make sure only the minimum number of file handles is left open
during a exec call. This is not a 100% solution, as there are also
some fopen() calls and, more importantly, file descriptors opened
by libraries. But it is better than nothing (and it was quick, at
least until we run into platform hell, what we will for sure ;)).
|
| |
| |
| |
| |
| | |
interestingly, they manifested on Debian, only, but potentially
existed on other platforms, too.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
primarily bugs introduced by recent changes. We now also handle
static file names correctly, that was not the case before. We
now correctly reset the descriptor in the dynafile cache if
somthing goes wrong.
Keep in mind that reliablity of output is depending on the
reliability of the file system driver (the cifs driver returns OK,
but still loses data if it is disconnected for too-long).
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- fixed a bug that caused action retries not to work correctly
situation was only cleared by a restart
- bugfix: closed dynafile was potentially never written until another
dynafile name was generated - potential loss of messages
|
| | | |
|