Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2720 > unrolled thread

Strange problem with rsyslog

Back to article view | Back to comp.os.linux.networking

Contents

  Strange problem with rsyslog Jarosław Rafa <raj@ap.krakow.pl> - 2014-02-14 09:16 +0100
    Re: Strange problem with rsyslog Joe Beanfish <joebeanfish@nospam.duh> - 2014-02-14 14:35 +0000
      Re: Strange problem with rsyslog Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-02-15 06:34 +0000
    Re: Strange problem with rsyslog Eric Pozharski <whynot@pozharski.name> - 2014-02-15 13:32 +0200

#2720 — Strange problem with rsyslog

I have a strange problem with rsyslog. I have experienced it on three
different machines with different OSes (Fedora, CentOS, Ubuntu) and
different rsyslog versions, have googled for solution to no avail. I
have no idea what might be going on, maybe someone can help?

The problem is, rsyslogd does not show in logs the messages coming in
from remote machines. Of course, I have the required directives $ModLoad
imudp and $UDPServerRun 514 in the config file, I have also put a
catch-all rule *.* /var/log/alllog on top of all the rules to not miss
any message. However, both in the alllog file and in the
other /var/log/* files there are only messages generated by the local
host.

Netstat shows that rsyslogd is listening on UDP port 514. Tcpdump shows
that messages from other machines are coming in at UDP port 514. But
rsyslogd even started in debug mode ("-d" switch) does not show any
trace of these messages (however, it informs precisely about any of the
local host generated messages).

What's more interesting, when I tried to send a test message from
another computer to rsyslog using a method I found on some forum:

echo "test message" | nc -w0 -u 192.168.2.5 514

(where 192.168.2.5 is the address of the problematic rsyslogd machine),
this message *is* logged by rsyslogd in the alllog file.

How to solve this???
-- 
Regards,
   Jaroslaw Rafa
   raj@ap.krakow.pl
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

[toc] | [next] | [standalone]

#2721

On Fri, 14 Feb 2014 09:16:42 +0100, Jarosław Rafa wrote:
> The problem is, rsyslogd does not show in logs the messages coming in
> from remote machines. Of course, I have the required directives $ModLoad
> imudp and $UDPServerRun 514 in the config file, I have also put a
> catch-all rule *.* /var/log/alllog on top of all the rules to not miss
> any message. However, both in the alllog file and in the other
> /var/log/* files there are only messages generated by the local host.
> 
> Netstat shows that rsyslogd is listening on UDP port 514. Tcpdump shows
> that messages from other machines are coming in at UDP port 514. But
> rsyslogd even started in debug mode ("-d" switch) does not show any
> trace of these messages (however, it informs precisely about any of the
> local host generated messages).
> 
> What's more interesting, when I tried to send a test message from
> another computer to rsyslog using a method I found on some forum:
> 
> echo "test message" | nc -w0 -u 192.168.2.5 514
> 
> (where 192.168.2.5 is the address of the problematic rsyslogd machine),
> this message *is* logged by rsyslogd in the alllog file.

I'm not thoroughly familiar with it, but check rsyslog.conf to see if
there's any setting that may be filtering/blocking/dropping things.

Compare the tcpdump of the working test to the real messages coming in
to find differences in payload that might be significant.

[toc] | [prev] | [next] | [standalone]

#2724

On Fri, 2014-02-14, Joe Beanfish wrote:
> On Fri, 14 Feb 2014 09:16:42 +0100, Jaros??aw Rafa wrote:
>> The problem is, rsyslogd does not show in logs the messages coming in
>> from remote machines. Of course, I have the required directives $ModLoad
>> imudp and $UDPServerRun 514 in the config file, I have also put a
>> catch-all rule *.* /var/log/alllog on top of all the rules to not miss
>> any message. However, both in the alllog file and in the other
>> /var/log/* files there are only messages generated by the local host.
>> 
>> Netstat shows that rsyslogd is listening on UDP port 514. Tcpdump shows
>> that messages from other machines are coming in at UDP port 514. But
>> rsyslogd even started in debug mode ("-d" switch) does not show any
>> trace of these messages (however, it informs precisely about any of the
>> local host generated messages).
>> 
>> What's more interesting, when I tried to send a test message from
>> another computer to rsyslog using a method I found on some forum:
>> 
>> echo "test message" | nc -w0 -u 192.168.2.5 514
>> 
>> (where 192.168.2.5 is the address of the problematic rsyslogd machine),
>> this message *is* logged by rsyslogd in the alllog file.
>
> I'm not thoroughly familiar with it, but check rsyslog.conf to see if
> there's any setting that may be filtering/blocking/dropping things.
>
> Compare the tcpdump of the working test to the real messages coming in
> to find differences in payload that might be significant.

Yes.  I /do/ know that a real message looks rather different from
"test message", but it's weird that a broken message would get through
and a normal one would not.

(A real message would encode things as facility, and I think also the
timestamp.)

Other than that, I agree with both of you.  I would also tcpdump and
so on.  strace(1) on rsyslogd too, except you have confirmed already
that it's actually listening.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2725

with <1392365801.1874.17.camel@Jarek> Jarosław Rafa wrote:

*SKIP*
> What's more interesting, when I tried to send a test message from
> another computer to rsyslog using a method I found on some forum:
>
> echo "test message" | nc -w0 -u 192.168.2.5 514
>
> (where 192.168.2.5 is the address of the problematic rsyslogd machine),
> this message *is* logged by rsyslogd in the alllog file.

That strongly suggests configuration problem.  Read carefully manpages
and example configuration files of rsyslogd.  Watch for words:
"accept", "deny", "filter", and "remote".  Check rsyslogd's manpage if
it can show its idea about what finaly configuration it works with (may
be in vein).

> How to solve this???

Personally, my choice is do-one-thing-and-do-it-good
'inetutils-syslogd'.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web