Red Hat Bugzilla – Bug 476239
Shorewall log is not directed to /var/log/messages
Last modified: 2009-11-18 08:47:13 EST
Description of problem:
After upgrading to latest shorewall (during F9 -> F10 update), shorewall log goes to the console instead of going into /var/log/message.
As a consequence, one cannot use console, because it is continously "garbled".
Version-Release number of selected component (if applicable):
After upgrade, console screen is continuosly garbled by the output of the shorewall log, instead ob being redirected to /var/log/messages.
Shorewall log should go into /var/log/messages or in a specialised log, if so chosen.
Thanks a lot,
Hm, that's bizarre - I don't see that behaviour at all. Can you describe your set up - what exactly are you doing when you see this output to the terminal?
Hello and thanks,
I'm doing nothing special.
I've just upgraded the system from F9 to F10 (via official DVD).
Now the output of shorewall goes to the console instead of the /var/log/messages file (not on *all* machines, on *some* of them). The output consists, mainly, from packets logged by shorewall, accepted or rejected, as requested by /etc/shorewall/rules. Since the machine is a production one, exposed to net, this output means high volume, a continuous flow.
Is there any parameter (debugging, maybe) in /etc/shorewall/shorewall.conf that I should check ?
Have a read of:
that may be some help.
Another thing to check is that you've not misconfigured syslog. This is very unlikely to be a shorewall bug.
Thanks for your information !
However, please note that I didn't perform *any* manual modification between Fedora 9 and Fedora 10. Just a normal upgrade, via official F10 DVD - that's all. In F9 I had no problem, in F10 yes.
Could you please suggest where to look ? Maybe a newer version of syslogd's configuration file is needed and this was not rewritten by rpm upgrade ?
Maybe some log is full and not cleared/rotated ? This machine has *a lot* of log entries, because it's a busy server...
Well, without a lot more information on your configuration (eg shorewall dump), and how you've set rsyslog up, what the messages being logged are, it's a bit difficult to help you further. It's certainly something you've misconfigured though - shorewall itself just sends log messages to rsyslog, and then rsyslog decides what to do with them based on how they're characterized.
Have you changed any of the options in shorewall.conf referring to logging from their default values? If so, I recommend putting them back to their defaults for now and then changing each one until you work out the problem.
is rsyslogd running? (ps aux | grep rsyslogd)
Have you read this thread:
Closing as NOTABU, but please feel free to re-open if you're able to provide more information and/or demonstrate this is a bug with shorewall.
Please help me find a positive solution to this.
Probably it's a syslog matter, not shorewall, but the problem remains.
I did nothing more than upgrading a functional F9 to F10, via official DVD. Apparently, nothing went wrong during upgrade - then this phenomenon occured.
No configuration file from the logging system was manually edited - all eventual modifications went via rpm, during package upgrade.
Today I've hit this on a second machine, in same conditions.
If there is an issue in the logging system, I'll be happy to help debugging - only instruct me where to look, please.
Reopening this and reassigning to rsyslog...
Thanks a lot,
Note that if you haven't changed any of the LOG variables in shorewall.conf, then the logging messages generated by the kernel as priority level 6/info. The relevan t part of man shorewall.conf is:
Many options have as their value a log-level. Log levels are a method
of describing to syslog (8) the importance of a message and a number of
parameters in this file have log levels as their value.
These levels are defined by syslog and are used to determine the
destination of the messages through entries in /etc/syslog.conf (5).
The syslog documentation refers to these as "priorities"; Netfilter
calls them "levels" and Shorewall also uses that term.
Valid levels are:
For most Shorewall logging, a level of 6 (info) is appropriate.
Shorewall log messages are generated by NetFilter and are logged using
facility ´kern´ and the level that you specifify. If you are unsure of
the level to choose, 6 (info) is a safe bet. You may specify levels by
name or by number.
Please see attached the /etc/shorewall/shorewall.conf file - upon me, has nothing strange.
In /etc/shorewall/rules I have macros with ":info", such as:
POP3/ACCEPT:info net $FW
Created attachment 328291 [details]
Right, nothing unusual about the logging options in shorewall.conf.
Next thing to look at is /etc/rsyslog.conf
Also, what happens if as root you do this command:
logger -p kern.info TESTKERNMESSAGE
Do you see TESTKERNMESSAGE on the console, or in /var/log/messages, or both?
I'll attach below the actual /etc/rsyslog.conf.
The output of "logger -p kern.info TESTKERNMESSAGE" DOES show up in the log when I do a:
tail -f /var/log/messages
(via ssh, 'cause I cannot use the physical console), but it DOESN'T show up on the garbled physical screen.
Created attachment 328625 [details]
The rsyslog.conf, as required
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Closing as insufficent data - can't reproduce, no new info from reporter.