ruby.git - Ruby GIT repository

diff options

author	akr <akr@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>	2004-02-01 17:42:08 +0000
committer	akr <akr@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>	2004-02-01 17:42:08 +0000
commit	fdde6a240b6c44d7b4ab0d1bccd70b13f096a9aa (patch)
tree	dc8e55093db4e2b63271e11ca54a19289c8efddc /sample/cbreak.rb
parent	99c3a88628ccfc56f3869c16a8df4531709e1986 (diff)
download	ruby-fdde6a240b6c44d7b4ab0d1bccd70b13f096a9aa.tar.gz ruby-fdde6a240b6c44d7b4ab0d1bccd70b13f096a9aa.tar.xz ruby-fdde6a240b6c44d7b4ab0d1bccd70b13f096a9aa.zip

exception message changed.

git-svn-id: http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8@5608 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Diffstat (limited to 'sample/cbreak.rb')

0 files changed, 0 insertions, 0 deletions

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head><title>Actions - rsyslog.conf</title></head> <body> This is a part of the rsyslog.conf documentation. <a href="rsyslog_conf.html">back</a> <h2>Actions</h2> The action field of a rule describes what to do with the message. In general, message content is written to a kind of "logfile". But also other actions might be done, like writing to a database table or forwarding to another host. Templates can be used with all actions. If used, the specified template is used to generate the message content (instead of the default template). To specify a template, write a semicolon after the action value immediately followed by the template name. Beware: templates MUST be defined BEFORE they are used. It is OK to define some templates, then use them in selector lines, define more templates and use use them in the following selector lines. But it is NOT permitted to use a template in a selector line that is above its definition. If you do this, the action will be ignored. You can have multiple actions for a single selector  (or more precisely a single filter of such a selector line). Each action must be on its own line and the line must start with an ampersand ('&') character and have no filters. An example would be <code>*.=crit rger & root & /var/log/critmsgs</code> These three lines send critical messages to the user rger and root and also store them in /var/log/critmsgs. Using multiple actions per selector is convenient and also offers a performance benefit. As the filter needs to be evaluated only once, there is less computation required to process the directive compared to the otherwise-equal config directives below: <code>*.=crit rger *.=crit root *.=crit /var/log/critmsgs</code>   <h3>Regular File</h3> Typically messages are logged to real files. The file has to be specified with full pathname, beginning with a slash "/''. You may prefix each entry with the minus "-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. If your system is connected to a reliable UPS and you receive lots of log data (e.g. firewall logs), it might be a very good idea to turn of syncing by specifying the "-" in front of the file name. The filename can be either static (always the same) or dynamic (different based on message received). The later is useful if you would automatically split messages into different files based on some message criteria. For example, dynamic file name selectors allow you to split messages into different files based on the host that sent them. With dynamic file names, everything is automatic and you do not need any filters. It works via the template system. First, you define a template for the file name. An example can be seen above in the description of template. We will use the "DynFile" template defined there. Dynamic filenames are indicated by specifying a questions mark "?" instead of a slash, followed by the template name. Thus, the selector line for our dynamic file name would look as follows: <blockquote> <code>*.* ?DynFile</code> </blockquote> That's all you need to do. Rsyslog will now automatically generate file names for you and store the right messages into the right files. Please note that the minus sign also works with dynamic file name selectors. Thus, to avoid syncing, you may use <blockquote> <code>*.* -?DynFile</code></blockquote> And of course you can use templates to specify the output format: <blockquote> <code>*.* ?DynFile;MyTemplate</code></blockquote> A word of caution: rsyslog creates files as needed. So if a new host is using your syslog server, rsyslog will automatically create a new file for it. Creating directories is also supported. For example you can use the hostname as directory and the program name as file name: <blockquote> <code>$template DynFile,"/var/log/%HOSTNAME%/%programname%.log"</code></blockquote> <h3>Named Pipes</h3> This version of rsyslogd(8) has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipe symbol ("|'') to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo(1) command before rsyslogd(8) is started. <h3>Terminal and Console</h3> If the file you specified is a tty, special tty-handling is done, same with /dev/console. <h3>Remote Machine</h3> Rsyslogd provides full remote logging, i.e. is able to send messages to a remote host running rsyslogd(8) and to receive messages from remote hosts. Using this feature you're able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs. Please note that this version of rsyslogd by default does NOT forward messages it has received from the network to another host. Specify the "-h" option to enable this. To forward messages to another host, prepend the hostname with the at sign ("@"). A single at sign means that messages will be forwarded via UDP protocol (the standard for syslog). If you prepend two at signs ("@@"), the messages will be transmitted via TCP. Please note that plain TCP based syslog is not officially standardized, but most major syslogds support it (e.g. syslog-ng or WinSyslog). The forwarding action indicator (at-sign) can be followed by one or more options. If they are given, they must be immediately (without a space) following the final at sign and be enclosed in parenthesis. The individual options must be separated by commas. The following options are right now defined: <table id="table2" border="1" width="100%"> <tbody> <tr> <td> z<number> </td> <td>Enable zlib-compression for the message. The <number> is the compression level. It can be 1 (lowest gain, lowest CPU overhead) to 9 (maximum compression, highest CPU overhead). The level can also be 0, which means "no compression". If given, the "z" option is ignored. So this does not make an awful lot of sense. There is hardly a difference between level 1 and 9 for typical syslog messages. You can expect a compression gain between 0% and 30% for typical messages. Very chatty messages may compress up to 50%, but this is seldom seen with typically traffic. Please note that rsyslogd checks the compression gain. Messages with 60 bytes or less will never be compressed. This is because compression gain is pretty unlikely and we prefer to save CPU cycles. Messages over that size are always compressed. However, it is checked if there is a gain in compression and only if there is, the compressed message is transmitted. Otherwise, the uncompressed messages is transmitted. This saves the receiver CPU cycles for decompression. It also prevents small message to actually become larger in compressed form. Please note that when a TCP transport is used, compression will also turn on syslog-transport-tls framing. See the "o" option for important information on the implications. Compressed messages are automatically detected and decompressed by the receiver. There is nothing that needs to be configured on the receiver side. </td> </tr> <tr> <td> o </td> <td>This option is experimental. Use at your own risk and only if you know why you need it! If in doubt, do NOT turn it on. This option is only valid for plain TCP based transports. It selects a different framing based on IETF internet draft syslog-transport-tls-06. This framing offers some benefits over traditional LF-based framing. However, the standardization effort is not yet complete. There may be changes in upcoming versions of this standard. Rsyslog will be kept in line with the standard. There is some chance that upcoming changes will be incompatible to the current specification. In this case, all systems using -transport-tls framing must be upgraded. There will be no effort made to retain compatibility between different versions of rsyslog. The primary reason for that is that it seems technically impossible to provide compatibility between some of those changes. So you should take this note very serious. It is not something we do not *like* to do (and may change our mind if enough people beg...), it is something we most probably *can not* do for technical reasons (aka: you can beg as much as you like, it won't change anything...). The most important implication is that compressed syslog messages via TCP must be considered with care. Unfortunately, it is technically impossible to transfer compressed records over traditional syslog plain tcp transports, so you are left with two evil choices... </td> </tr> </tbody> </table> The hostname may be followed by a colon and the destination port. The following is an example selector line with forwarding: *.*    @@(o,z9)192.168.0.1:1470 In this example, messages are forwarded via plain TCP with experimental framing and maximum compression to the host 192.168.0.1 at port 1470. *.* @192.168.0.1 In the example above, messages are forwarded via UDP to the machine 192.168.0.1, the destination port defaults to 514. Messages will not be compressed. Note that IPv6 addresses contain colons. So if an IPv6 address is specified in the hostname part, rsyslogd could not detect where the IP address ends and where the port starts. There is a syntax extension to support this: put squary brackets around the address (e.g. "[2001::1]"). Square brackets also work with real host names and IPv4 addresses, too.


context:
space:
mode: