rsyslog

The rocket-fast system for log processing

Search Results for: error 235

rsyslog error 2357

By Rainer GerhardsPosted on Posted in UncategorizedTagged No Comments on rsyslog error 2357

Warning parsing config file.

This unfortunately is a pretty generic error code which is emitted when there is a problem understanding the configuration files. The main configuration file is usually /etc/rsyslog.conf and it may include other configuration files. The error message names the file and the approximate location of the error.

The error text should describe what needs to be fixed. If that does not help, it may make sense to check out rsyslog support options.

This is a stub entry: If you have questions please post a comment or visit the github issue tracker.

rsyslog error 2359

By adisconteamPosted on Posted in UncategorizedTagged No Comments on rsyslog error 2359

Status: action was resumed (used for reporting).

This means a previously suspended action has recovered. Recovery happens e.g. when the action can reconnect to a server or some resource starvation is solved. This is an informational message telling you rsyslog now executes the action again.

Note: due to a bug in old rsyslog versions (e.g. 8.24.0) an “action was suspended” message is not necessarily reported. Thus the resumption message may be the only way to detect something went wrong. Version 8.1904.0 and above will much more reliably report action suspension.

If you have questions please post a comment or visit the github issue tracker.

rsyslog error 2354

By adisconteamPosted on Posted in UncategorizedTagged 1 Comment on rsyslog error 2354

Sending msg via UDP failed.

This may have several causes. To differentiate between them, the OS error code (so-called “errno”) and the OS error description is given. Note that rsyslog does not know more about the error cause than shown in its message.

An example is (OS parts in red):

rsyslogd: omfwd: error 11 sending via udp: Resource temporarily unavailable

The message above most probably indicates that the system is out of UDP buffer space. But it may have different causes (e.g. out of sockets). If you can’t find an easy solution, you need to monitor your system.

Note that old versions (like 8.24) always failed to send messages close to or larger than 64KiB.

If you have questions please post a comment or visit the github issue tracker.

librelp 1.2.16

By Rainer GerhardsPosted on Posted in 1.2.16, APITagged ,

librelp 1.2.16 [download]

This new release of librelp provides API changes that allow better handling of oversize messages, as well as defining the listener interface. In addition, a few bugfixes for memory leaks and several minor issues are included.

For more details, please take a look at the changelog below.

———————————————————————-
– API changes
  * add new API: relpSrvSetOversizeMode()
    This permits to tell librelp how to handle oversize messages.
    Traditionally (and now default), this aborts the session. We now
    added an option to truncate the message instead.
    Also, in case of session abort a descriptive error message is
    emitted. This did not happen previously and caused confusion.
    closes https://github.com/rsyslog/librelp/issues/81
  * add new API: relpSrvSetLstnAddr()
    It permits to set the listen address inside the relp server.
    If not called, the server will bind to all interfaces. 
    Thanks to github user perlei for contributing it.
– support additional hashes for fingerprint mode
  old-style SHA1 is used automatically
  Thanks to github user briaeros for the patch.
  see also https://github.com/rsyslog/librelp/pull/55
– bugfix: potential memory leak
  This is very unlikely to occur in practice. Memory can be leaked
  when TLS initialization fails when the client tries to connect
  to the server. However, if this actually happens, it can happen
  frequently and so accumulate to a large leak.
  No report of such occurence from practice.
  Detected by Coverity Scan, CID 266008.
– bugfix: memory leak on protocol error
  Receiving relp frames are not correctly deallocated while handling
  protocol errors resulting in memory leak of dirty pages.
  Thanks to github user gleentea for the patch.
  see also https://github.com/rsyslog/librelp/issues/59
  closes https://github.com/rsyslog/librelp/issues/60
– fixed a couple of minor issues:
  * fix memory leak when relp frame construction fails
    detected by clang static analyzer
  * removed unnecessary code
    detected by clang static analyzer
  * fix memory leak
    This leaks occurs if the process is already totally out of memory,
    a situation that is very rare and will also cuase other troubles.
    So the practical relevance of this patch looks rather slim.
    Detected by clang static analyzer.
  * fix memory leak on relpSrvRun() error
    this is kind of cosmetic, because it can only occur when the
    run fails, which usually should lead to termination of the
    calling application
    deteced by Coverity Scan, CID 266016
  * fix memory leak on relp listener construction error
    detected by Coverity Scan, CID 266014, 266015
  * also resolved all other issues reported by Coverity scan
– CI
  * added native testbench (formerly used rsyslog for testing)
  * added additional compile tests


sha256sum: 0c235dd2a01060ad5e64438879b31ae64e7640d0e262aa1a287a2dd9bc60fd53

Scroll to top