I just upgraded from 4.7 today, using Tom's recommended guidelines on his announcement post. I had no issues with any of the drives, but I was looking at the syslog and noticed this:

 

So, 192.168.1.123 is a netgear powerline adapter.

 

It's not causing any issues, but I don't want the syslog to get gigantic from the constant warning message in the syslog, which might fill the flash drive eventually (which *will* cause problems).

 

I'm not really sure what to do about this.

 

Any ideas?

 

Edit: It seems like I might be able to modify "etc/syslog.conf" to filter these messages (so they don't ever appear in the syslog), but I'm unsure of the syntax.

syslog-2013-10-05_2.zip

Looking at my latest 4.7 log on 10/4/2013, I don't see any of these messages.

Ask Lime to reduce avahi logging. You could write a script that removes the lines once per day.

Bear with me, I'm a Windows user.

 

Ok, I tried to write a script and have it run every 5 minutes.

 

I created a file: "/boot/custom/parsesylog":

 

*/5 * * * * sed -i '/Received response from host .* with invalid source port .* on interface/d' /var/log/syslog
*/5 * * * * sed -i '/Invalid legacy unicast query packet/d' /var/log/syslog

 

In "/boot/config/go":

 

cat /boot/custom/parsesyslog >> /var/spool/cron/crontabs/root

 

The idea is that I remove the two offending lines that are spamming my syslog every 5 minutes with this script.

 

When I run the commands normally, i.e.,

 

sed -i '/Received response from host .* with invalid source port .* on interface/d' /var/log/syslog
sed -i '/Invalid legacy unicast query packet/d' /var/log/syslog

 

The syslog is pruned successfully.

 

However, once the script runs via cron, something weird happens and the it seems only the first removal works --- all the "Invalid legacy unicast query packet" lines remain.

 

I've attached both syslogs, one which is a minute after boot, BEFORE cron runs the "parsesyslog" script, and one 5 minutes later, AFTER cron runs the "parsesyslog" script.

 

Furthermore, it seems that the syslog is then "locked"... nothing else seems to write to the syslog properly. You'll see in file "syslog-2013-10-06-BEFORE.txt" on line 1431 it shows that I telnet in from my machine. Once the script runs, the syslog no longer seems to capture the telnet (I tried repeatedly, and the syslog never appends anything else). Note: even when running the /sbin/powerdown script, this normally captures a ton of stuff in the syslog, but once looking at the archived log file in /boot/logs, it doesn't show anything. So something is getting messed up.

 

Does linux have file handles like Windows? Perhaps sed is causing the file to be locked?

 

Does anyone know what I might be doing wrong here?

syslog-2013-10-06.zip

As a followup, I did a "lsof /var/log" to figure out if there was an open file handle (after the script was run) and I got this:

 

COMMAND  PID USER    FD     TYPE DEVICE SIZE/OFF NODE NAME
syslogd 1195 root    1w     REG    0,13   151090 4605 /var/log/syslog (deleted)

 

I'm guessing that "sed -i" must delete the file and then copy back... and somehow this causes the syslog daemon to lose the handle on the syslog file?

add

 

/etc/rc.d/rc.syslog restart

 

to restart logging.

 

 */5 * * * * sed -i '/Received response from host .* with invalid source port .* on interface/d' /var/log/syslog; /etc/rc.d/rc.syslog restart
*/5 * * * * sed -i '/Invalid legacy unicast query packet/d' /var/log/syslog; /etc/rc.d/rc.syslog restart

Thanks, I just figured this out and it seems to work (although it triggers an email from the unraid-status-email plugin, strangely enough).

Two problems with what you're doing:

1) syslogd doesn't allow others to modify the syslog -- if you try, it will stop logging to it.  You'll have stop the daemon, do whatever changes to the log, thn start the daemon again.  But you will lose important messages that come during that time.  Bad idea.

2) the way you do that through crond, it will start two separate instances of sed at the same time, and you'll have race condition, as each of the two stream editors will write to their own copies of the syslog and than try rename it back to syslog.  Bad idea.  Instead of going through crond, you may as well have a single script with one infinite loop and a 5 min sleep inside it.  But still a bad idea.

 

In general, meddling with the syslog is a BAD idea!  Instead, look into the config files of whatever is writing those lines (avahi?) and adjust the log level there.

 

It's not causing any issues, but I don't want the syslog to get gigantic from the constant warning message in the syslog, which might fill the flash drive eventually (which *will* cause problems).

That can't happen.  syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose).  In v.5, the syslog is in a size-limited tmpfs in RAM.  So nothing bad will happen as a result of its growing.  It will just stop growing once it reaches a certain size (128MB?  grep /var/log /proc/mounts).  That may take a very long time though.

 

 

2) the way you do that through crond, it will start two separate instances of sed at the same time, and you'll have race condition, as each of the two stream editors will write to their own copies of the syslog and than try rename it back to syslog.  Bad idea.  Instead of going through crond, you may as well have a single script with one infinite loop and a 5 min sleep inside it.  But still a bad idea.

 

I've modified the script to only use 1 sed command.

 

In general, meddling with the syslog is a BAD idea!  Instead, look into the config files of whatever is writing those lines (avahi?) and adjust the log level there.

 

I agree, although I have no idea on how to adjust the log level for the syslogd. Can you point me in the right direction?

 

I found some filtering capabilities in syslogs, although they seem to come from differing variants of syslog, such as rsyslog or syslog-ng. I couldn't find anything about filtering messages in the "vanilla" syslogd.

 

That can't happen.  syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose).  In v.5, the syslog is in a size-limited tmpfs in RAM.  So nothing bad will happen as a result of its growing.  It will just stop growing once it reaches a certain size (128MB?  grep /var/log /proc/mounts).  That may take a very long time though.

 

I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place?

In general, meddling with the syslog is a BAD idea!  Instead, look into the config files of whatever is writing those lines (avahi?) and adjust the log level there.

I agree, although I have no idea on how to adjust the log level for the syslogd.

I didn't mean the syslogd config, I meant the avahi-daemon config, wherever that is.

(I don't use avahi so I can't help you with that.)

 

That can't happen.  syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose).  In v.5, the syslog is in a size-limited tmpfs in RAM.  So nothing bad will happen as a result of its growing.  It will just stop growing once it reaches a certain size (128MB?  grep /var/log /proc/mounts).  That may take a very long time though.

I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place?

You are looking in the right place.  What are you confused about?

 

 

I've modified the script to only use 1 sed command.

Still, don't modify the syslog.  (And, not through crond.)

 

I have no idea on how to adjust the log level for the syslogd.

The syslog priority levels, in ascending order are: debug, info, notice, warning, error, emerg.

Stock unRAID uses the highest log level -- debug -- logs everything.

 

So you could lower the log level with something like this:

mv /etc/syslog.conf /etc/syslog.conf.bak
echo '*.info	-/var/log/syslog' >/etc/syslog.conf
/etc/rc.d/rc.syslog restart

Is the syslog still getting spammed? If yes, try lowering some more:

echo '*.notice	-/var/log/syslog' >/etc/syslog.conf
/etc/rc.d/rc.syslog restart

...etc.

 

While the above may help you, it is still better to deal with the offending program's settings (avahi-daemon?), rather than messing with the syslogd conf settings.

 

 

That can't happen.  syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose).  In v.5, the syslog is in a size-limited tmpfs in RAM.  So nothing bad will happen as a result of its growing.  It will just stop growing once it reaches a certain size (128MB?  grep /var/log /proc/mounts).  That may take a very long time though.

I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place?

You are looking in the right place.  What are you confused about?

 

Well, since "/var/log/syslog" resides on the flash drive, I was confused that you were saying that syslogd doesn't write to the flash drive. Maybe I'm mistaken about where "/var/log/syslog" actually sits -- I don't really know much about linux.

 

The syslog priority levels, in ascending order are: debug, info, notice, warning, error, emerg.

Stock unRAID uses the highest log level -- debug -- logs everything.

 

So you could lower the log level with something like this:

mv /etc/syslog.conf /etc/syslog.conf.bak
echo '*.info	-/var/log/syslog' >/etc/syslog.conf
/etc/rc.d/rc.syslog restart

Is the syslog still getting spammed? If yes, try lowering some more:

echo '*.notice	-/var/log/syslog' >/etc/syslog.conf
/etc/rc.d/rc.syslog restart

...etc.

 

While the above may help you, it is still better to deal with the offending program's settings (avahi-daemon?), rather than messing with the syslogd conf settings.

 

Ok thanks, I'll look into that. I'm basically using stock unRaid with the latest unmenu (which doesn't have anything to do with this avahi spam, AFAIK), so the avahi-daemon message is coming from the unraid package, which is what I'm trying to solve.

 

Thanks for your help. I'll see if I can reduce the logging.

That can't happen.  syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose).  In v.5, the syslog is in a size-limited tmpfs in RAM.  So nothing bad will happen as a result of its growing.  It will just stop growing once it reaches a certain size (128MB?  grep /var/log /proc/mounts).  That may take a very long time though.

I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place?

You are looking in the right place.  What are you confused about?

Well, since "/var/log/syslog" resides on the flash drive...

Wrong.  unRAID's whole directory structure resides in RAM.  Only what's mounted on the /boot/ directory is actually your flash drive.

 

 

Bear with me, I'm a Windows user.

This just struck me:  Do you even have any Apple computers on your network? (Do you even need Avahi?)

 

If not, then just a single line in your "go" script will fix all this for you:

for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

 

 

for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

 

I don't have any Macs on my network, so I guess I don't need avahi. However, this didn't seem to do anything (avahi still spammed the syslog).

 

mv /etc/syslog.conf /etc/syslog.conf.bak
echo '*.info	-/var/log/syslog' >/etc/syslog.conf
/etc/rc.d/rc.syslog restart

 

This worked. Thanks for your help!

for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

I don't have any Macs on my network, so I guess I don't need avahi.

However, this didn't seem to do anything (avahi still spammed the syslog).

Did you put the above line in your "go" script, and then reboot?

If so, then the avahi daemon will not be started at boot, so how can it still spam your syslog?

 

 

for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

I don't have any Macs on my network, so I guess I don't need avahi.

However, this didn't seem to do anything (avahi still spammed the syslog).

Did you put the above line in your "go" script, and then reboot?

If so, then the avahi daemon will not be started at boot, so how can it still spam your syslog?

 

I don't know what to tell you, but it didn't work. I edited "/boot/config/go" and added the line above and rebooted. After reboot, I'm still seeing the messages.

 

The other fix worked, though. Thanks for that.

Bear with me, I'm a Windows user.

This just struck me:  Do you even have any Apple computers on your network? (Do you even need Avahi?)

 

If not, then just a single line in your "go" script will fix all this for you:

for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

 

I don't have any mac's on my network either what are the advantages of doing this, is it worth doing?

I don't have any mac's on my network either what are the advantages of doing this, is it worth doing?

 

This isn't something you really need to do unless you have problems like mine.