Barziya

Members
  • Posts

    79
  • Joined

  • Last visited

Everything posted by Barziya

  1. 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?
  2. 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
  3. 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.
  4. 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.
  5. Still, don't modify the syslog. (And, not through crond.) 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.
  6. 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.) 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?
  7. Wake me up when the Subject line says "$150 WD Red 4TB"
  8. 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.
  9. 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. 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.
  10. 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?
  11. Right. That's not the subject of this thread though. We were trying to trouble shoot a particular problem.
  12. 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.
  13. 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.
  14. 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.
  15. 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..
  16. With 4gb of ram in your server you could still benefit from using that option. The server behaves differently with it.
  17. 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).
  18. 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.
  19. when you try the intel nic remember to disable the onboard nics in the bios
  20. 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.
  21. I see you're still running in 8GB of ram. Do you have the same intermittent problem when you boot with the mem=4095M option? I see this board has nForce NICs. Just a shot in the dark here, but do you by any chance have an Intel NIC you could try with?
  22. Yes. UnRAID's package base is from Slackware version from like five years ago. But don't worry about that. Crond crapping out is the only side effect of using the newer glibc. If you don't really need crond on your server, then you can just kill the thing, and ignore the problem. Or, if you don't need the compiler packages on a daily basis, you can just install them when you actually have to do some compiling. Or, you could get the older gcc/make/binutls/glibc/etc., but why bother?
  23. The question about total cost of ownership is kind of pointless. They have different strengths. To mention a few: -- With unRAID, every data disk has its own file system. In emmergency, you can take a data disk from unRAID and read it in another machine. You can't do that with FreeNAS. -- If it so happens that two disks fail at the same time (with single parity), with FreeNAS you lose everything. With unRAID you'll lose only the files on the two failed disks. (with luck, one of the two failed disks will be the parity disk). Furthermore, you could still attempt some data recovery from the failed unRAID disks, while with FreeNAS disks that would be pointless. -- With unRAID you can have only one disk spinning and all the other disks nicely spun down while you're watching a movie. With FreeNAS all disks will be spinning. -- FreeNAS has ZFS, with embedded checksumming and automatic data recovery, double-parity RAID-Z, file system snapshots, etc., etc.. All that can be priceless. -- So, Apple vs Orange -- total cost of ownership?
  24. No, it wasn't fixed. If you review that thread -- was it around RC14 or something -- you'll see that Tom ended up deciding between two possible solutions: #1: Make a 64-bit kernel. (That would have been the real fix.) and #2: Make the new RC with a mem=4095M option in the boot menu. (That is not really a fix, but a workaround.) At the end Tom decided to go with #2. So he posted a RC with that boot option, and immediately people started screaming that their servers were crashing -- people with less that 4GB RAM of course. So what Tom did was he immediately posted yet another RC the next day removing that option from the boot menu, and called it a fix for the crashing servers -- no mention of the original problem that called for the 'mem=' workaround in the first place. And that was the end of it. That was the "fix" you remember. Here are two quotes from Linus that are quite relevant to the matter: http://lkml.org/lkml/2013/4/29/512 http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/