fnwc Posted October 5, 2013 Share Posted October 5, 2013 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 Quote Link to comment
fnwc Posted October 5, 2013 Author Share Posted October 5, 2013 Looking at my latest 4.7 log on 10/4/2013, I don't see any of these messages. Quote Link to comment
dgaschk Posted October 5, 2013 Share Posted October 5, 2013 Ask Lime to reduce avahi logging. You could write a script that removes the lines once per day. Quote Link to comment
fnwc Posted October 7, 2013 Author Share Posted October 7, 2013 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 Quote Link to comment
fnwc Posted October 7, 2013 Author Share Posted October 7, 2013 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? Quote Link to comment
dgaschk Posted October 7, 2013 Share Posted October 7, 2013 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 Quote Link to comment
fnwc Posted October 7, 2013 Author Share Posted October 7, 2013 Thanks, I just figured this out and it seems to work (although it triggers an email from the unraid-status-email plugin, strangely enough). Quote Link to comment
Barziya Posted October 7, 2013 Share Posted October 7, 2013 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. Quote Link to comment
fnwc Posted October 7, 2013 Author Share Posted October 7, 2013 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? Quote Link to comment
Barziya Posted October 7, 2013 Share Posted October 7, 2013 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? Quote Link to comment
Barziya Posted October 7, 2013 Share Posted October 7, 2013 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. Quote Link to comment
fnwc Posted October 7, 2013 Author Share Posted October 7, 2013 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. Quote Link to comment
Barziya Posted October 7, 2013 Share Posted October 7, 2013 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. Quote Link to comment
Barziya Posted October 7, 2013 Share Posted October 7, 2013 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 Quote Link to comment
fnwc Posted October 8, 2013 Author Share Posted October 8, 2013 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! Quote Link to comment
Barziya Posted October 8, 2013 Share Posted October 8, 2013 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? Quote Link to comment
fnwc Posted October 8, 2013 Author Share Posted October 8, 2013 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. Quote Link to comment
Harpz Posted October 8, 2013 Share Posted October 8, 2013 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? Quote Link to comment
fnwc Posted October 9, 2013 Author Share Posted October 9, 2013 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.