Barziya
-
Posts
79 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Barziya
-
-
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?
-
Thanks for the help but that didn't seem to work either and neither ... p4-clockmod since it was built into the kernel.
Did you actually do it? What did `cpufreq-info | grep driver` show after the reboot?
Can you post a syslog from after the reboot, so I can see the effect of the blacklist option?
-
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'll try rolling back to RC 14... are there any issues I need to be aware of in downgrading?
Only the whole list of changes in the Release Notes, from RC14 all the way to 5.0-final. For one example, around RC14 a bug in reiserfs was discovered that could lead to data loss. But if such things don't bother you, then you'll be OK.
-
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.
-
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.
-
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?
-
Wake me up when the Subject line says "$150 WD Red 4TB"
-
Teracopy is a free program which allows to copy and perform checksums, you can find it here: http://codesector.com/teracopy
It would have been a great feature if TeraCopy had the option to save checksum files alongside whatever files it copied. That would save us the huge time waste to read a BIG file twice -- once when creating a checksum file for it, and a second time when copying that file to the server. If you are copying from a *nux machine, then you can accomplish the whole thing in a single pass with a tee command in a pipe. I haven't found any nice GUI with such functionality for Windows though.
-
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.
-
Is there anything else i can do?
A few things come to mind. Try this:
sysctl -w net.core.rmem_default=163840 sysctl -w net.core.wmem_default=163840 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_rmem='4096 131072 16777216' sysctl -w net.ipv4.tcp_wmem='4096 131072 16777216' sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_mtu_probing=1 ifconfig eth0 txqueuelen 3000 ifconfig eth1 txqueuelen 3000 sysctl -w net.core.netdev_max_backlog=3000 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 sysctl -w vm.min_free_kbytes=65536 read xx MEM xx <<<`grep 'MemTotal:' /proc/meminfo` if [ "$MEM" -gt 2048000 ] ;then sysctl -w vm.min_free_kbytes=131072 ;fi
With the above tweaks applied, can you still reproduce the "network name is no longer available" problem?
-
Yup, I did comment it out but it still loads the p4-clockmod module
Then blacklist it. Modify this line in the syslinux.cfg file like this:
append p4-clockmod.blacklist=yes initrd=bzroot
...and reboot. Then...
cpufreq-info | grep driver
-
...full slackware 64bit installation.. There are quite a few features that I would find useful that aren't in the appliance-like unraid build.
Right. That's not the subject of this thread though. We were trying to trouble shoot a particular problem.
-
root@Tower:~# cpufreq-info
analyzing CPU 0:
driver: p4-clockmod
The p4-clockmod driver has always been problematic. Many people chose to outright blacklist that driver. Can't you use something like the acpi-cpufreq driver instead? What's your CPU anyway?
-
After getting to that point, with how much system resources i have and the lack of virtualizing, i will probably go full slackware64 14.1 and add a video/sound card with xbmc.
Do you mean like abandoning unRAID? Or, do you mean making all that work in unRAID?
Either way, good luck with that. Let us know how it goes.
-
...installing full slackware 64bit install...
You don't need a full Slackware install for that, just the kernel.
You can easily test that theory like this:
- Grab the latest prebuilt kernel from the Slackware-64 repo, and the corresponding kernel modules;
- Repack unRAID's bzroot to insert the new kernel modules folder in it;
- Add an entry in syslinux.cfg that uses the new kernel and the repackaged bzroot;
- Edit the go script to NOT start emhttp;
- Reboot;
- Start Samba manually;
- Test to see if you still have that problem or not.
If that turns out that this makes your problem go away, then you can easily build yourself a new kernel with the unRAID's driver as module for it. Then you can happily use all the ram you can fit in that server, no need to limit anything.
-
limiting to 4GB does not change anything with the error.
limiting to 4GB did fix the error for me on the following servers:
- Supermicro X8SIL-F + Xeon X3440
- Supermicro X7DBE + 2x Xeon L5420
- Supermicro H8DAE + 2x Opteron 275
The problem was reproduceable not only with unRAID, but with other 32-bit distros with PAE.
BTW, an alternative way to make the problem go away was booting a 64-bit kernel. (with the same 32-bit userspace)
If the mem option doesn't fix it for you, then you must have other problems on top of that. Your nForce NIC is a prime suspect, as mentioned in earlier post.
-
does the server use different logic or follow a different code path or something?
Yes. You can try it and see for yourself how it allocates the memory.
That fork has two paths:
#1: mem is less than 4gb. (Disables all PAE crap.)
#2: mem is not less than 4gb. i.e., it is 4gb-or-more. (Uses signifficant chunks of precious lowmem just to keep track of highmem.)
So your 4gb is not a special case -- it falls under #2, just like 8gb or 16gb etc..
-
How does the server behave differently
4095M < 4GB
`free -l`
-
I just started having the same problem today. I only have 4gb of ram on my server.
With 4gb of ram in your server you could still benefit from using that option. The server behaves differently with it.
-
if I read the multiple WiKi properly you can run it much the same as unRaid mode but with benefits of checksum and self healing.
That is not correct. In unRAID, the md-mod driver takes care of the redundant array, while each data drive has its own independant file system. If you wand a self healing BTRFS, then you'll have to let the BTRFS filesystem itself be in charge of disk redundancy. But then there's no place for the unRAID's md-mod driver in that picture -- you lose all the unique features of unRAID.
You could possibly have independent BTRFS file systems on each data disk, all on top of unRAID's md-mod driver, but then those individual BTRFS file systems won't be self healing, as they will have no knowledge of the redindancy. That will also require some reworking of the md-mod driver, because (as of this writing) it crashes with anything other than reiserfs (I've tried that).
-
do i have to physically pull the ram?
don't have to physically pull out anything. already told you in earlier post you can just add that option in syslinux.cfg and then reboot.
This is a boot option that will appear on an attached monitor every time the system boots.
Not in version 5.0. He'll have to add it himself, like in this post, and then reboot.
-
I do believe i have an intel nic around, just have to make sure the slots are available.
when you try the intel nic remember to disable the onboard nics in the bios
-
do i have to physically pull the ram?
don't have to physically pull out anything. already told you in earlier post you can just add that option in syslinux.cfg and then reboot.
5.0 Final: Possible bug in cpu frequency scaling.
in unRAID 5.x OS Issue List
Posted
That's so very strange! I've always had success blacklisting modules that way. (for example, the ancient ide piix driver, which for some unknown reason is still in unRAID.) You're right, it doesn't look good. Perhaps Limetech will show some mercy and remove the p4-clockmod from the kernel in the next release. (you'll have to email him about that).