[CentOS-docs] contributing to CentOS
Hello there, I've used CentOS for awhile. Really like that distro and am thinking of contributing to the effort. So now I am trying to follow the instructions here: http://wiki.centos.org/Contribute (Section 3) My CentOS wiki login is: BorisEpstein The subject on contributions to the Wiki - whatever I know. I have experience configuring CentOS boxes as OpenVPN, NIS, print servers, etc. You are asking for a proposed location. I am not sure what kind of location is referred to there. Also, I could contribute using my IT and programming experience and knowledge. Here's my resume: http://technonutsnbolts.blogspot.com/2011/10/resume.html Cheers, Boris. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS] Centso 6.2 bug ?
Hello, is anyone experiencing this ? I have a sympa process (bulk.pl) which triggers this bug: [ cut here ] WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Not tainted) Hardware name: X8DTU-LN4+ Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support igb ioatdma dca i7core_edac edac_core sg ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif usb_storage pata_acpi ata_generic ata_piix sata_mv dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 2241, comm: bulk.pl Not tainted 2.6.32-220.2.1.el6.x86_64 #1 Call Trace: [81069997] ? warn_slowpath_common+0x87/0xc0 [810699ea] ? warn_slowpath_null+0x1a/0x20 [814eccc5] ? thread_return+0x232/0x79d [810958e3] ? __hrtimer_start_range_ns+0x1a3/0x460 [814ee5db] ? do_nanosleep+0x8b/0xc0 [81095da4] ? hrtimer_nanosleep+0xc4/0x180 [81094b70] ? hrtimer_wakeup+0x0/0x30 [81095bd4] ? hrtimer_start_range_ns+0x14/0x20 [81095ed4] ? sys_nanosleep+0x74/0x80 [8100b0f2] ? system_call_fastpath+ thank you Rick ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centso 6.2 bug ?
Am 22.01.2012 14:08, schrieb Riccardo Veraldi: Hello, is anyone experiencing this ? I have a sympa process (bulk.pl) which triggers this bug: [ cut here ] WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Not tainted) Hardware name: X8DTU-LN4+ Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support igb ioatdma dca i7core_edac edac_core sg ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif usb_storage pata_acpi ata_generic ata_piix sata_mv dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 2241, comm: bulk.pl Not tainted 2.6.32-220.2.1.el6.x86_64 #1 Call Trace: [81069997] ? warn_slowpath_common+0x87/0xc0 [810699ea] ? warn_slowpath_null+0x1a/0x20 [814eccc5] ? thread_return+0x232/0x79d [810958e3] ? __hrtimer_start_range_ns+0x1a3/0x460 [814ee5db] ? do_nanosleep+0x8b/0xc0 [81095da4] ? hrtimer_nanosleep+0xc4/0x180 [81094b70] ? hrtimer_wakeup+0x0/0x30 [81095bd4] ? hrtimer_start_range_ns+0x14/0x20 [81095ed4] ? sys_nanosleep+0x74/0x80 [8100b0f2] ? system_call_fastpath+ thank you Rick http://lists.centos.org/pipermail/centos/2012-January/122311.html Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Problem with spamassassin under CentOS-5.7
I'm getting the following warning in my logwatch, or if I restart the spamassassin service. I've tried yum-reinstalling the packages involved but that didn't help. --- /etc/cron.daily/sa-learn: Subroutine IO::Socket::INET6::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/IO/Socket/INET6.pm line 16 Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread- multi/Net/DNS/Resolver/Base.pm line 66 Learned tokens from 1 message(s) (1 message(s) examined) --- I wonder if anyone else is getting this? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem with spamassassin under CentOS-5.7
Am 22.01.2012 14:22, schrieb Timothy Murphy: I'm getting the following warning in my logwatch, or if I restart the spamassassin service. I've tried yum-reinstalling the packages involved but that didn't help. --- /etc/cron.daily/sa-learn: Subroutine IO::Socket::INET6::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/IO/Socket/INET6.pm line 16 Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread- multi/Net/DNS/Resolver/Base.pm line 66 Learned tokens from 1 message(s) (1 message(s) examined) --- I wonder if anyone else is getting this? There has been a long thread about it very recently http://lists.centos.org/pipermail/centos/2012-January/121652.html Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] weird XFS problem
Hello all, I have a CentOS 5.7 machine hosting a 16 TB XFS partition used to house backups. The backups are run via rsync/rsnapshot and are large in terms of the number of files: over 10 million each. Now the machine is not particularly powerful: it is 64-bit machine, dual core CPU, 3 GB RAM. So perhaps this is a factor in why I am having the following problem: once in awhile that XFS partition starts generating multiple I/O errors, files that had content become 0 byte, directories disappear, etc. Every time a reboot fixes that, however. So far I've looked at logs but could not find a cause of precipitating event. Hence the question: has anyone experienced anything along those lines? What could be the cause of this? Thanks. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centso 6.2 bug ?
On Sun, Jan 22, 2012 at 5:08 AM, Riccardo Veraldi riccardo.vera...@cnaf.infn.it wrote: Hello, is anyone experiencing this ? I have a sympa process (bulk.pl) which triggers this bug: [ cut here ] WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Not tainted) Hardware name: X8DTU-LN4+ You can find more info in this centos bug report: http://bugs.centos.org/view.php?id=5371 Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 9:06 AM, Boris Epstein borepst...@gmail.com wrote: Hello all, I have a CentOS 5.7 machine hosting a 16 TB XFS partition used to house backups. The backups are run via rsync/rsnapshot and are large in terms of the number of files: over 10 million each. Now the machine is not particularly powerful: it is 64-bit machine, dual core CPU, 3 GB RAM. So perhaps this is a factor in why I am having the following problem: once in awhile that XFS partition starts generating multiple I/O errors, files that had content become 0 byte, directories disappear, etc. Every time a reboot fixes that, however. So far I've looked at logs but could not find a cause of precipitating event. Hence the question: has anyone experienced anything along those lines? What could be the cause of this? Thanks. Boris. Correction to the above: the XFS partition is 26TB, not 16 TB (not that it should matter in the context of this particular situation). Also, here's somethine else I have discovered. Apparently there is an potential intermittent RAID disk trouble. At least I found the following in the system log: Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0026): Drive ECC error reported:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x002D): Source drive error occurred:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0004): Rebuild failed:unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x003B): Rebuild paused:unit=0. ... Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:56:17 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x000B): Rebuild started:unit=0. Even if a disk is misbehaving in a RAID6 that should not be causing I/O errors. Plus, why is it never straight after a rebbot and is always fixed by a reboot? Be that as it may, I am still puzzled. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS and LessFS
On Jan 17, 2012, at 4:00 PM, Hugh E Cruickshank h...@forsoft.com wrote: From: Les Mikesell Sent: January 17, 2012 05:56 Big disks are cheap these days - I wouldn't worry that much about the total space that much and you'll still be able to keep a lot online. This is true for current hardware however I am attempting to reuse our existing hardware that has been pulled from our production systems. It tends to be older technology but still usable. In this case, it is a set of disk arrays using SCSI3 drives. The db's are probably best handled in a pre-backup script that dumps/compresses them, then excluding the live files - and then even block de-dup won't help. Pst's are a problem any way you look at them but more because of Outlook's locking than their size. Backuppc is packaged in EPEL so it's easy to install and shows the compression and file re-use stats so you'll know in a few runs how it will handle your data. While all of this is true I was kind of hoping that I could come up with something that was more plug and play. The LessFS looked promising. I will continue to check this concept out further (be it LessFS, ZFS, or something else) but I am going to be avoiding the bleeding edge and can only afford to spend a limited amount of time chasing this down before I have to bite the bullet and go with what we have. Thanks again of your feedback and to all the others who have responded. Everyone's comments have been greatly appreciated. If this is only a 1-2 year temporary solution and the backups will be discarded once a permanent solution is obtained then I'm sure it will be OK. If your thinking of building a long-term backup solution this way then your building your castles on a foundation of sand. As backup sets grow and hardware/software ages you may find yourself in a technological dead-end unable to migrate the data off and unable to continue going forward. If it is such an essential thing as backups (it's backup data right not redundant systems?) then I suggest telling the client to open their wallet cause when the shit hits the fan you either have solid backups or you have bankruptcy courts. Buy a Data Domain, Exagrid or Falconstor backup storage appliance with builtin compression/de-duplication that is fully supported and has a viable upgrade path. Use a good centralized backup platform such as netbackup, networker, etc. The investment made in backup is an investment in the business' future. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
Now the machine is not particularly powerful: it is 64-bit machine, dual core CPU, 3 GB RAM. So perhaps this is a factor in why I am having the following problem: once in awhile that XFS partition starts generating multiple I/O errors, files that had content become 0 byte, directories disappear, etc. Every time a reboot fixes that, however. So far I've looked at logs but could not find a cause of precipitating event. Is the CentOS you are running a 64 bit one? The reason I am asking this is because the use of XFS under a 32 bit OS is NOT recommended. If you search this list's archives you will find some discussion about this subject. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
Correction to the above: the XFS partition is 26TB, not 16 TB (not that it should matter in the context of this particular situation). Yes, it does matter: Read this: *[CentOS] 32-bit kernel+XFS+16.xTB filesystem = potential disaster* http://lists.centos.org/pipermail/centos/2011-April/109142.html ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 2:27 PM, Miguel Medalha miguelmeda...@sapo.ptwrote: Correction to the above: the XFS partition is 26TB, not 16 TB (not that it should matter in the context of this particular situation). Yes, it does matter: Read this: *[CentOS] 32-bit kernel+XFS+16.xTB filesystem = potential disaster* http://lists.centos.org/**pipermail/centos/2011-April/**109142.htmlhttp://lists.centos.org/pipermail/centos/2011-April/109142.html Miguel, Thanks, but based on the uname output: uname -a Linux nrims-bs 2.6.18-274.12.1.el5xen #1 SMP Tue Nov 29 14:18:21 EST 2011 x86_64 x86_64 x86_64 GNU/Linux this is clearly a 64-bit OS so the 32-bit limitations ought not to apply. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
uname -a Linux nrims-bs 2.6.18-274.12.1.el5xen #1 SMP Tue Nov 29 14:18:21 EST 2011 x86_64 x86_64 x86_64 GNU/Linux this is clearly a 64-bit OS so the 32-bit limitations ought not to apply. Ok! Since you didn't inform us in your initial post, I thought I should ask you in order to eliminate that possible cause. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
Nevertheless, it seems to me that you should have more than 3GB of RAM on a 64 bit system... Since the width of the binary word is 64 bit in this case, 3GB correspond to 1.5GB on a 32 bit system... If you have a 64 bit system you should give it space to work properly. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
Nevertheless, it seems to me that you should have more than 3GB of RAM on a 64 bit system... Since the width of the binary word is 64 bit in this case, 3GB correspond to 1.5GB on a 32 bit system... If you have a 64 bit system you should give it space to work properly. ... and the fact that a reboot seems to fix the problem could also point in that direction. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 2:35 PM, Miguel Medalha miguelmeda...@sapo.ptwrote: Nevertheless, it seems to me that you should have more than 3GB of RAM on a 64 bit system... Since the width of the binary word is 64 bit in this case, 3GB correspond to 1.5GB on a 32 bit system... If you have a 64 bit system you should give it space to work properly. Don't worry, you asked exactly the right question - but, unfortunately, it is not a 32-bit OS here that's the culprit so the situation is more involved than that. You are right - it would indeed be desirable to have more than 3 GB of RAM on that system. However it is not obvious to me that having that little RAM should cause I/O failure? Why? That it would make the machine slow is to be expected - and especially so given that I had to jack the swap up to some 40 GB. But I do not necessarily see why I should have outright failures due solely to not having more RAM. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 2:37 PM, Miguel Medalha miguelmeda...@sapo.ptwrote: Nevertheless, it seems to me that you should have more than 3GB of RAM on a 64 bit system... Since the width of the binary word is 64 bit in this case, 3GB correspond to 1.5GB on a 32 bit system... If you have a 64 bit system you should give it space to work properly. ... and the fact that a reboot seems to fix the problem could also point in that direction. That is entirely possible. It does seem to me that some sort of a resourse accumulation is indeed occurring on the system - and I hope there is a way to stop that because filesystem I/O should be a self-balancing process. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
You are right - it would indeed be desirable to have more than 3 GB of RAM on that system. However it is not obvious to me that having that little RAM should cause I/O failure? Why? That it would make the machine slow is to be expected - and especially so given that I had to jack the swap up to some 40 GB. But I do not necessarily see why I should have outright failures due solely to not having more RAM. If I were you, I would be monitoring the system's memory usage. Maybe some software component has a memory leak which keeps worsening until a reboot cleans it. Also, I wouldn't discard the possibility of a physical memory problem. Can you test it? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 2:43 PM, Miguel Medalha miguelmeda...@sapo.ptwrote: You are right - it would indeed be desirable to have more than 3 GB of RAM on that system. However it is not obvious to me that having that little RAM should cause I/O failure? Why? That it would make the machine slow is to be expected - and especially so given that I had to jack the swap up to some 40 GB. But I do not necessarily see why I should have outright failures due solely to not having more RAM. If I were you, I would be monitoring the system's memory usage. Maybe some software component has a memory leak which keeps worsening until a reboot cleans it. Also, I wouldn't discard the possibility of a physical memory problem. Can you test it? Miguel, thanks! All that you are saying makes perfect sense. I have tried monitoring the system to see if any memory hogs emerge and found no obvious culprits thus far. I.e., there are processes running that consume large volumes or RAM but none that seem to keep growing overtime. Or at least I failed to locate such processes thus far. As for testing the RAM - it is always a good test when in doubt. Too bad you have to stop your machine in order to do it and for that reason I haven't done it yet. Though this is on the short list of things to try. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
I have a CentOS 5.7 machine hosting a 16 TB XFS partition used to house backups. The backups are run via rsync/rsnapshot and are large in terms of the number of files: over 10 million each. Now the machine is not particularly powerful: it is 64-bit machine, dual core CPU, 3 GB RAM. So perhaps this is a factor in why I am having the following problem: once in awhile that XFS partition starts generating multiple I/O errors, files that had content become 0 byte, directories disappear, etc. Every time a reboot fixes that, however. So far I've looked at logs but could not find a cause of precipitating event. Hence the question: has anyone experienced anything along those lines? What could be the cause of this? In every situation like this that I have seen, it was hardware that never had adequate memory provisioned. Another consideration is you almost certainly wont be able to run a repair on that fs with so little ram. Finally, it would be interesting to know how you architected the storage hardware. Hardware raid, BBC, drive cache status, barrier status etc... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 2:56 PM, Joseph L. Casale jcas...@activenetwerx.com wrote: I have a CentOS 5.7 machine hosting a 16 TB XFS partition used to house backups. The backups are run via rsync/rsnapshot and are large in terms of the number of files: over 10 million each. Now the machine is not particularly powerful: it is 64-bit machine, dual core CPU, 3 GB RAM. So perhaps this is a factor in why I am having the following problem: once in awhile that XFS partition starts generating multiple I/O errors, files that had content become 0 byte, directories disappear, etc. Every time a reboot fixes that, however. So far I've looked at logs but could not find a cause of precipitating event. Hence the question: has anyone experienced anything along those lines? What could be the cause of this? In every situation like this that I have seen, it was hardware that never had adequate memory provisioned. Another consideration is you almost certainly wont be able to run a repair on that fs with so little ram. Finally, it would be interesting to know how you architected the storage hardware. Hardware raid, BBC, drive cache status, barrier status etc... Joseph, If I remember correctly I pretty much went with the defaults when I created this XFS on top of a 16-drive RAID6 configuration. Now as far as memory - I think for the purpose of XFS repair RAM and swap ought to be the same. And I've got plenty of swap on this system. I also host an 5 TB XFS in a file there and I ran XFS repair on it and it ran within no more than 5 minutes. Now this is 20% of the larger XFS, roughly speaking. I should try to collect the info you mentioned, though - that was a good thought, some clue might be contained in there for sure. Thanks for your input. Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS and LessFS
On Sun, Jan 22, 2012 at 12:00 PM, Ross Walker rswwal...@gmail.com wrote: If this is only a 1-2 year temporary solution and the backups will be discarded once a permanent solution is obtained then I'm sure it will be OK. If your thinking of building a long-term backup solution this way then your building your castles on a foundation of sand. As backup sets grow and hardware/software ages you may find yourself in a technological dead-end unable to migrate the data off and unable to continue going forward. On the other hand, if you have a predictable churn of high performance production boxes being replaced every few years, tossing a few new big cheap drives into a still nice but retired server and starting over is a very attractive option. You don't need to migrate anything - just keep the old box around until the replacement has the history you need to keep. Buy a Data Domain, Exagrid or Falconstor backup storage appliance with builtin compression/de-duplication that is fully supported and has a viable upgrade path. Use a good centralized backup platform such as netbackup, networker, etc. The investment made in backup is an investment in the business' future. There's a place for those, but probably not for someone who doesn't even want to buy new drives. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Jan 22, 2012, at 10:00 AM, Boris Epstein borepst...@gmail.com wrote: Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0026): Drive ECC error reported:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x002D): Source drive error occurred:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0004): Rebuild failed:unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x003B): Rebuild paused:unit=0. From 3ware's site: 004h Rebuild failed The 3ware RAID controller was unable to complete a rebuild operation. This error can be caused by drive errors on either the source or the destination of the rebuild. However, due to ATA drives' ability to reallocate sectors on write errors, the rebuild failure is most likely caused by the source drive of the rebuild detecting some sort of read error. The default operation of the 3ware RAID controller is to abort a rebuild if an error is encountered. If it is desired to continue on error, you can set the Continue on Source Error During Rebuild policy for the unit on the Controller Settings page in 3DM. 026h Drive ECC error reported This AEN may be sent when a drive returns the ECC error response to an 3ware RAID controller command. The AEN may or may not be associated with a host command. Internal operations such as Background Media Scan post this AEN whenever drive ECC errors are detected. Drive ECC errors are an indication of a problem with grown defects on a particular drive. For redundant arrays, this typically means that dynamic sector repair would be invoked (see AEN 023h). For non-redundant arrays (JBOD, RAID 0 and degraded arrays), drive ECC errors result in the 3ware RAID controller returning failed status to the associated host command. Sounds awfully like a hardware error on one of the drives. Replace the failed drive and try rebuilding. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Jan 22, 2012, at 4:41 PM, Ross Walker rswwal...@gmail.com wrote: On Jan 22, 2012, at 10:00 AM, Boris Epstein borepst...@gmail.com wrote: Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0026): Drive ECC error reported:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x002D): Source drive error occurred:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0004): Rebuild failed:unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x003B): Rebuild paused:unit=0. From 3ware's site: 004h Rebuild failed The 3ware RAID controller was unable to complete a rebuild operation. This error can be caused by drive errors on either the source or the destination of the rebuild. However, due to ATA drives' ability to reallocate sectors on write errors, the rebuild failure is most likely caused by the source drive of the rebuild detecting some sort of read error. The default operation of the 3ware RAID controller is to abort a rebuild if an error is encountered. If it is desired to continue on error, you can set the Continue on Source Error During Rebuild policy for the unit on the Controller Settings page in 3DM. 026h Drive ECC error reported This AEN may be sent when a drive returns the ECC error response to an 3ware RAID controller command. The AEN may or may not be associated with a host command. Internal operations such as Background Media Scan post this AEN whenever drive ECC errors are detected. Drive ECC errors are an indication of a problem with grown defects on a particular drive. For redundant arrays, this typically means that dynamic sector repair would be invoked (see AEN 023h). For non-redundant arrays (JBOD, RAID 0 and degraded arrays), drive ECC errors result in the 3ware RAID controller returning failed status to the associated host command. Sounds awfully like a hardware error on one of the drives. Replace the failed drive and try rebuilding. This error code does not bode well. 02Dh Source drive error occurred If an error is encountered during a rebuild operation, this AEN is generated if the error was on a source drive of the rebuild. Knowing if the error occurred on the source or the destination of the rebuild is useful for troubleshooting. It's possible the whole RAID6 is corrupt. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On 2012-01-22, Boris Epstein borepst...@gmail.com wrote: Also, here's somethine else I have discovered. Apparently there is an potential intermittent RAID disk trouble. At least I found the following in the system log: Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0026): Drive ECC error reported:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x002D): Source drive error occurred:port=4, unit=0. Which 3ware controller is this? I have had lots of problems with the 3ware 9550SX controller and WD-EA[RD]S drives in a similar configuration. (Yes, I know all about the EARS drives, but they work mostly fine with the 3ware 9650 controller, so I suspect some weird interaction between the cheap drives and the old not-so-great controller. I also suspect an intermittently failing port, which I'll be testing more later this week.) Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:56:17 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x000B): Rebuild started:unit=0. What does your RAID look like? Are you using the 3ware's RAID6 (in which case it's not a 9550) or mdraid? Are the 3ware errors in the logs across a large number of ports or just a few? Have you used the drive tester for your drives to verify that they're still good? On all my other systems, when the controller has reported a failure, and I've run it through the tester, it's reported a failure. (Often when my 9550 reports a failure the drive passes all tests.) If you happen to have real RAID drive models, you may also try contacting LSI support. They will steadfastly refuse to help if you have desktop-edition drives, but can be at least somewhat helpful if you have enterprise drives. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On Sun, Jan 22, 2012 at 1:34 PM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2012-01-22, Boris Epstein borepst...@gmail.com wrote: Also, here's somethine else I have discovered. Apparently there is an potential intermittent RAID disk trouble. At least I found the following in the system log: Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x0026): Drive ECC error reported:port=4, unit=0. Jan 22 09:17:53 nrims-bs kernel: 3w-9xxx: scsi6: AEN: ERROR (0x04:0x002D): Source drive error occurred:port=4, unit=0. Which 3ware controller is this? I have had lots of problems with the 3ware 9550SX controller and WD-EA[RD]S drives in a similar configuration. (Yes, I know all about the EARS drives, but they work mostly fine with the 3ware 9650 controller, so I suspect some weird interaction between the cheap drives and the old not-so-great controller. I also suspect an intermittently failing port, which I'll be testing more later this week.) Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:55:23 nrims-bs kernel: 3w-9xxx: scsi6: AEN: WARNING (0x04:0x000F): SMART threshold exceeded:port=9. Jan 22 09:56:17 nrims-bs kernel: 3w-9xxx: scsi6: AEN: INFO (0x04:0x000B): Rebuild started:unit=0. What does your RAID look like? Are you using the 3ware's RAID6 (in which case it's not a 9550) or mdraid? Are the 3ware errors in the logs across a large number of ports or just a few? Have you used the drive tester for your drives to verify that they're still good? On all my other systems, when the controller has reported a failure, and I've run it through the tester, it's reported a failure. (Often when my 9550 reports a failure the drive passes all tests.) If you happen to have real RAID drive models, you may also try contacting LSI support. They will steadfastly refuse to help if you have desktop-edition drives, but can be at least somewhat helpful if you have enterprise drives. --keith -- kkel...@wombat.san-francisco.ca.us Keith, thanks! The RAID is on the controller level. Yes, I believe the controller is a 3Ware 9xxx series - I don't recall the details right now. What are you referring to as drive tester? Boris. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] squid transparent proxy problem
Please verify you resolv.conf João Rodrigues On Sat, Jan 21, 2012 at 10:33 PM, Hüvely Balázs balazs.huv...@gmail.comwrote: Greetings, I installed a squid 3.1.10.i686 squid to a centos 6.2i686. The proxy is working fine with the default config. After I decided to use it as a transparent proxy, I added two lines to config: http_proxy 10.0.5.1:3128 transparent, always_direct allow all http_port 10.0.5.1:3128 transparent # # Recommended minimum configuration: # acl manager proto cache_object #acl localhost src 127.0.0.1/32 ::1 acl localhost src 127.0.0.1/32 #acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.0.0.0/8 # RFC1918 possible internal network #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network #acl localnet src 192.168.0.0/16# RFC1918 possible internal network #acl localnet src fc00::/7 # RFC 4193 local private network range #acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # # Recommended minimum Access Permission configuration: # # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on localhost is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 http_port 3128 # We recommend you to use at least the following line. hierarchy_stoplist cgi-bin ? # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/spool/squid # Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 always_direct allow all There are 2 iptables rule too: -A PREROUTING -i lo -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 eth0 is the local NIC, eth1 is for internet. ipv4_forward is enabled. [root@atom squid]# iptables -S -t nat -P PREROUTING ACCEPT -P POSTROUTING ACCEPT -P OUTPUT ACCEPT -A PREROUTING -i lo -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 -A POSTROUTING -o eth1 -j MASQUERADE [root@atom squid]# iptables -S -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i tun+ -j ACCEPT -A INPUT -i eth0 -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -j DROP -A FORWARD -j ACCEPT -A OUTPUT -j ACCEPT The cache.log tells me about strange errors: 2012/01/22 00:23:51| Starting Squid Cache version 3.1.4 for i386-koji-linux-gnu... 2012/01/22 00:23:51| Process ID 4981 2012/01/22 00:23:51| With 1024 file descriptors available 2012/01/22 00:23:51| Initializing IP Cache... 2012/01/22 00:23:51| DNS Socket created at [::], FD 7 2012/01/22 00:23:51| Adding nameserver 192.168.4.254 from /etc/resolv.conf 2012/01/22 00:23:51| Adding nameserver 192.168.5.254 from /etc/resolv.conf 2012/01/22 00:23:51| User-Agent logging is disabled. 2012/01/22 00:23:51| Referer logging is disabled. 2012/01/22 00:23:51| Unlinkd pipe opened on FD 12 2012/01/22 00:23:51| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec 2012/01/22 00:23:51| Store logging disabled 2012/01/22
Re: [CentOS] Problem with spamassassin under CentOS-5.7
Alexander Dalloz wrote: I'm getting the following warning in my logwatch, or if I restart the spamassassin service. I've tried yum-reinstalling the packages involved but that didn't help. --- /etc/cron.daily/sa-learn: Subroutine IO::Socket::INET6::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/IO/Socket/INET6.pm line 16 Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread- multi/Net/DNS/Resolver/Base.pm line 66 Learned tokens from 1 message(s) (1 message(s) examined) --- I wonder if anyone else is getting this? There has been a long thread about it very recently http://lists.centos.org/pipermail/centos/2012-January/121652.html Thanks, I missed that. I found the recipe near the end of the thread solved the problem for me. rpm -e --nodeps perl-NetAddr-IP vi /etc/yum.repos.d/rpmforge.repo -- change all enabled = 1 to enabled = 0 temporarily (seems like yum priorities is going to be a good idea) -- yum install perl-NetAddr-IP -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS and LessFS
On Mon, 2012-01-16 at 15:50 -0800, Hugh E Cruickshank wrote: We have been looking at implementing deduplication on a backup server. From what I have been able to find the available documentation is pretty thin. I ended up trying to install LessFS on this CentOS 5.7 box but we have now encountered problems with fuse version Has anyone out there been able to get LessFS running on CentOS 5.7 and can provide some pointers If not LessFS can you suggest an alternate deduplication software? SFDS / openDEDUPE http://wmmi.net/documents/OpenDedup.pdf http://www.opendedup.org/ -- Adam Tauno Williams http://www.whitemiceconsulting.com System Administrator, OpenGroupware Developer, LPI / CNA Fingerprint 8C08 209A FBE3 C41A DD2F A270 2D17 8FA4 D95E D383 signature.asc Description: This is a digitally signed message part ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird XFS problem
On 2012-01-22, Boris Epstein borepst...@gmail.com wrote: The RAID is on the controller level. Yes, I believe the controller is a 3Ware 9xxx series - I don't recall the details right now. The details are important in this context--the 9550 is the problematic one (at least for me, though I've seen others with similar issues). But if it's a hardware RAID6, it's a later controller, as the 9550 doesn't support RAID6. I have had some issues with the WD-EARS drives with 96xx controllers, but much less frequently. What are you referring to as drive tester? Some drive vendors distribute their own bootable CD image, with which you can run tests specific to their drives, which can return proper error codes to help determine whether there is actually a problem on the drive. Seagate used to require you give them the diagnostic code their tester returned in order for them to accept a drive for an RMA; I don't think they do that any more, but they still distribute their tester. But it's a good way to get another indicator of a problem; if both the controller and the drive tester report an error, it's very likely that you have a bad drive; if the tester says the drive is fine, and does this for a few drives the controller reports as failed, you can suspect something behind the drives as a problem. (This is how I came to suspect the 9550: it would say my drives had failed, but the WD tester repeatedly said they were fine.) The latest version of UBCD has the latest versions of these various testers; I recall WD, Seagate, and Hitachi testers, and I'm pretty sure there are others. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS6 KDE: Desktop Activity type: desktop only
Hello Phil, On Fri, 20 Jan 2012 18:39:03 -0500 Phil Schaffner philip.r.schaff...@nasa.gov wrote: wwp wrote on 01/20/2012 09:56 AM: Hello there, I'm looking at different desktop activity types (in Desktop Settings), and on my CentOS 6, I only have desktop. No folderview, for instance. Does anybody know how to install/enable other types? I have Desktop (default) and Folder View. How did you install KDE? I picked it at installation time and took the defaults. Might try yum groupinstall KDE Desktop I don't remember exactly how I installed the KDE stuff, but the `yum groupinstall KDE Desktop` command did work, thanks a lot! Now I see Folder View as a possible desktop activity type. Regards, -- wwp signature.asc Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
