So that I don't lose my router logs, I have my Cellspot router configured to send its logs to a Linux computer on my network. I also have the router configured to get its time from the NTP server pool.ntp.org. Both of these features work fine except that when NTP updates occur (hourly, on the hour), the log information is not just routed to the logging computer, it is also broadcast on the console screen of the logging computer, and with each message there is a beep. While once/hour doesn't seem that intrusive, sometimes the update requires several tries before it succeeds (I'm not sure what the cause of that is), so instead of one message & beep per hour, there are 4 or 5 or 7 messages and beeps within a few seconds. It is still not a huge deal, but it's bothersome enough that I am writing about it here, hoping someone knows how to get the broadcasts to stop, and have the router just send the log file entry like it does with every other message getting logged.
And I know it's a long shot, but if I don't ask and someone does have an answer, I'll never know about it, so here it is. Please reply if you have a solution! Thanks.
could it be your linux install catching these log messages and beeping them as if they're happening on the machine?
A log is a log. The router has no control over the machine it is spitting to, so the "spittee" machine is parsing something and thus beeping. I'd check there.
Yep, I'd thought of that, but thus far can't find anything on the Linux box that would cause it. That doesn't mean it's not responsible, just that I can't find it. Any idea why a zillion "kernel:" messages would NOT behave this way, and only "ntp:" messages do?
are you logging the stuff into their own folder (not /logs)?
I'm guessing whatever is parsing the logs finds certain keywords in what's coming out and is sysprinting them to the console (dang my linux lingo is out of date, and I've got a cast on my right arm, so researching more is too intensive -- heck, typing this is..)
If you want all beeping gone, you can disable pcspkr (google 'blacklist pcspkr')
I may have found the answer - haven't had time to check it on my system
yet. Have a look at:
that's about what I was trying to suggest
As it turns out, that was not the answer. As I was reading that page and before I had taken any action based on it, I noticed that the messages seemed to have stopped. I checked a couple of ssh consoles that I had left active overnight, and sure enough, there were no ntp updates being displayed on them! And I verified that the update messages were getting into the log file, so the logging was still functioning, but not being echoed to the console. Here is what apparently did the trick...
When setting up the linux box to accept the router logs, I entered this into the /etc/rsyslog.conf file:
# Accept log data from Cellspot Router
:fromhost-ip,isequal,"<router's ip>" -?cellspot
This set it up to create a new log file daily - today's is 'cellspot-2015-10-30.txt'. Yesterday I noticed that all the data going into those files was being duplicated in the kern.log file. When looking into the cause of that, I found that I needed to add a line to the rsyslog file:
The &~ tells rsyslog to log the entry in the cellspot file, then stop logging it, i.e. don't put the entry in any other files. I verified right away that the router entries had stopped going into the kernel log file, and apparently that also caused the messages to stop hitting the console. IOW, it was only messages going to kern.log that were echoed to the console, so once that stopped, so did the console messages.
So the bottom line is that you were right to suspect the linux box. Thanks for prodding me to look into it in more depth!
Wow! I posted a rather lengthy reply that was showing as "Being moderated"
or something similar, and after awhile it was deleted! Which is a shame
because it contained the answer (which was not in the link referenced
earlier as it turns out). I'll try a shorter version this time and hope it
The problem was on the syslog server machine, as suspected. In the rsyslog
file where the cellspot logging was configured, I needed to add a line
containing &~ beneath the new lines I had entered. Without this, the
cellspot logs were being duplicated in kern.log, and when the ntp update
messages hit the kern.log file, they were also echoed to the console. I'm
still not sure why they were being echoed to the console, but once they
stopped hitting kern.log, the console messages also stopped.
So, as I stated in my deleted reply, you were right to suspect something
the linux box, and I thank you for prodding me to look deeper into it!
On Fri, Oct 30, 2015 at 1:40 PM, smplyunprdctble <email@example.com>
Whoops, my bad... I thought an earlier reply had been deleted, but I see now that it's still "Currently being moderated". Assuming it (post #6 in this thread) clears moderation and remains, posts 7 and 8 can be removed. Thanks.
Retrieving data ...