1) The most likely cause is that you did not select SYSLOG listening during your
ConsoleWorks installation.
To fix this, edit the file
/opt/ConsoleWorks/invocation_name/CWExports.sh where invocation_name
is the name you of your ConsoleWorks invocation. This will be
default if you did not pick a name. Change the line that reads
CONWRKS_SYSLOG_DISABLE="Y"
to
CONWRKS_SYSLOG_DISABLE="N"
then stop and restart ConsoleWorks
# /opt/ConsoleWorks/bin/cw_stop.sh
# /opt/ConsoleWorks/bin/cw_start.sh
to enable it to listen for SYSLOG messages. You should now be able to create
consoles that use SYSLOG as the type of connection. They will be able to
receive and process SYSLOG messages.
Note that you do need a SYSLOG connector license in order to create SYSLOG
connections. Our Customer Support personnel or your sales representative
will be happy to help you obtain a SYSLOG connector license.
(The example above applies specifically to Linux. Other platforms will need appropriate adjustments to path specifications.)
2) Check that ConsoleWorks was able to bind to the port (you may have another syslog listener already running.) To check this, look for bind errors in the invocation's .out file. Alternately, run netstat on the ConsoleWorks server machine while ConsoleWorks is not running. Look for the desired syslog port in use. If you find some other syslogd running, disable it, and restart ConsoleWorks.
3) Look for an "unsolicited syslog" entry in the CONWRKS console log. If one or more is present, your basic syslog listener is working, but it may mean your device has more than one NIC and may be sending syslog entries on a NIC (IP address) other than the one for which your syslog console is configured.
Go to directory C:\Program Files\TDi\ConsoleWorks Windows Event Forwarder
and use the following command:
ConsoleWorksWEFService -testsyslog
This will generate an artificial syslog event to the CONWRKS console device.
The CONWRKS device logfile will show the detection of this event.
back to top ^