Discuss

discuss@lists.centos.org

34753 discussions

Too much memory cache being used while moving large file
by Sean O Sullivan 01 Dec '05

01 Dec '05

System : CentOS 4.2 2.6.9-22.0.1.ELsmp System fully up-to-date. 3GB RAM 3ware 9000S card, with Raid5 array. I think that's about all relevant info ... Had file on disk (not array), attempted to mv file to array. Went fine till 2.4GB was copied, then it slowed down to a meg every few minutes. Free memory was ~50MB (Typically is 1.5-2GB), and cache was 2.5GB. Stopped the move, however cache not being cleared out -- and this issue continues to happen - unsure if it was always a problem/known issue, it does however only occur when copying a single file > 2.4GB (I have copied 5+GB of 1+GB files in the past without issue). Also, saw following in dmesg while this was going on: Out of Memory: Killed process 12467 (mysqld). I'll be restarting server later on tonight, which will 'fix' immediate problem, however just curious on thoughts in regards to this. Regards, Sean O Sullivan

4 7

Installed Kernal (default)
by Sam Drinkard 01 Dec '05

01 Dec '05

Is there a description or statement that describes the stock kernal in CentOS, and would give all the various modules it is compiled with? As with BSD, I assume there are things in the kernal that are mandatory, and then there are things that are optional or included so as to catch most everything one could have w/r/t hardware. That being the case, as with FreeBSD, removing those unneded modules would work to reduce the size of the kernal. Aside from rebuilding the kernal to have it contain certain objects needed for something to work, and the loading of different modules at runtime, are there any other benefits to building a custom kernal for any particular set of hardware? By leaving the modules not needed, how much, if any, overhead does this contribute to size? Is this sort of the way things work under Linux, or am I all wet in my thinking? -- Snowman

5 7

A minor beef
by Collins Richey 01 Dec '05

01 Dec '05

CentOS is a really great product, and the package supporters do a bang up job, but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates. I know this is whin[ge]ing, and I certainly don't have a solution to offer. If anyone can offer bucks and/or equipment to improved the software distribution process, your karma would get an enormous boost!!! -- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan

23 74

Squid updates break tunneling
by Tim Edwards 30 Nov '05

30 Nov '05

This is a question I posted to the RHEL3 mailing list but didn't get a response: "We are currently running squid-2.5.STABLE3-6.3E.9 on one of our RHEL3 proxy servers because updating to the latest (squid-2.5.STABLE3-6.3E.14) seems to break any kind of tunelling, ie. things like instant messaging ports and ssh using proxytunnel (http://proxytunnel.sourceforge.net/) Has anyone else experienced this problem with the Squid updates from RHN?" I was wondering if anyone running Centos has any advice/info on this? -- Tim Edwards

1 0

Yum / Up2date issues and mirror.centos.org
by Johnny Hughes 30 Nov '05

30 Nov '05

There have been some complaints recently concerning this, so I thought an explanation of the setup AND recommendations are in order. First, I want to say that we need more donated servers with fast (at least 100mbit) internet connections. If you are making lots of money using CentOS and are a hosting provider, please consider providing us a donated server so we can better distribute CentOS. Now on to the message :) ----------------------------------------- 1. mirror.centos.org is a rrdns of several machines, so that we can distribute the load for CentOS downloads across several servers. Distributed load is the only way we can serve more than 1 TiB per day for updates. (That's right, 1 TiB per day, ~30TiB per month, double the traffic of 3 months ago, 10x the traffic of a year ago). We had several servers totally maxed out serving updates during the 4.2 release cycle. Did I mention server donations :) There are other ways to distribute the load other than rrdns ... like a load balancer ... but these usually only work well with geographically co-located machines. Since all our machines for mirror.centos.org rrdns are donated and they are disbursed throughout the US and EU. They don't work well with the typical load balancing. 2. Since our machines are not geographically co-located, we need to come up with another method to use multiple servers to distribute load. We are currently developing an application that will use geoip (and public mirrors that we verify are updated: http://www.centos.org/modules/tinycontent/index.php?id=13 along with the donated mirror.centos.org servers) to generate a mirrorlist for each country identified by geoip. This mirrorlist should then have good, fast and geographically accurate servers for each person who does updates. We hope to have this system functioning properly before the release of CentOS-4.3 and CentOS-3.7. If you use the optional fastestmirror plugin, you will even get the fastest mirror in each repo from the mirrorlist. The fastestmirror plugin is currently under heavy development by the people at yum (in which CentOS is helping) ... so it is going to change in the next couple months, but in it's current form it works well for those not on proxy servers to pick the fastest mirrors from a list. http://lists.centos.org/pipermail/centos-devel/2005-November/000947.html 3. Another common problem is transparent proxy servers and yum. HTTP mirrors and yum don't work really well via transparent proxy servers, so if you are using one, your best bet is to pick an FTP mirror from our public external server list (see mirror link above) instead of mirror.centos.org. ------------------------------- So, what can you do now if you have problems ... or just want to help. First thing is to pick several close mirrors and not use mirror.centos.org in your /etc/yum.repos.d/CentOS-Base.conf file. There is an example of a repo with more than 1 mirror in the fastestmirror link above. If you have more than 1 mirror for each repo (I recommend that you do) ... and if you don't have to use yum via a proxy server that blocks outbound client connections ... then you should try the fastestmirror plugin above to pick your best mirror from the list at yum run time. We will continue to strive to deliver CentOS within our means as we continue to grow by leaps and bounds, but we need the help and support of our user community if we are going to be able to continue to provide the same stellar services that we have all grown accustomed to. That means people who use CentOS will need to support it ... that is what the Community ENTerprise Operating System (CentOS) is all about. Thanks, Johnny Hughes

10 50

RE: [CentOS] Building rpms
by Bowie Bailey 30 Nov '05

30 Nov '05

From: Craig White [mailto:craigwhite@azapple.com] > On Wed, 2005-11-30 at 12:53 -0600, Johnny Hughes wrote: > > > > What is the purpose of the LDAP upgrade ... if it is security you are > > worried about ... those get in there. > > > > See this: > > http://www.redhat.com/advice/speaks_backport.html > > > > When you start changing major components, you greatly reduce the > > stability of CentOS for yourself ... and you ruin the system > > interoperability. > ---- > I pretty much agree with that last statement - and could never > conceive of getting an rpm of openldap/servers/client from Fedora > and rebuilding it on RHEL/CentOS without it being really really > tough to build and not breaking anything. > > I think the general consensus on openldap message base is to build > everything in /usr/local from source, which in my case, I built db4 > (4.2.52+patches), kerberos, cyrus-sasl, openssl and then finally > openldap - all from source and it wasn't nearly as hard as I feared > and left RHEL stuff alone and didn't break anything. The information > that I used to do this all came from Quanah's web pages at > Stanford... > http://www.stanford.edu/services/directory/openldap/ I'm looking at doing that. I was just trying to stay with RPMs if possible so that I don't run in to dependency issues later when I try to install an RPM that requires openldap. > Perhaps a less painful method might be to use Buchan Milne's rpm's > which would do much the same and though they seem to be created for > Mandriva, apparently can build/install on RHEL (sorry, I don't have > a URL for this but you can either post to openldap list or search > their archives). Not a bad idea. Anyone tried this on CentOS4? > Lastly, perhaps the least painful method of all is the pretty much > turnkey packages available from symas... <http://www.symas.com> Interesting. I may look into this. > Now, generally Red Hat back port works well enough but if you are > going to make RHEL/CentOS the base of a large directory service... > 2.0.7-20 (CentOS3) and 2.2.13-4 (CentOS4) simply don't cut it for a > number of reasons. I stick with them on most of my installations > because the number of users and the extent of the demands that I put > upon ldap are pretty minimal but if you are going to have a > substantial investment in time/energy in ldap, > fahgettibouddit...install current. That's about what we determined. > Recognize that 2.2.30 (I believe) is still the latest categorized > 'stable' - 2.3.11 (and I think it is now up to 2.3.12) is discussed > and sometimes casually referred to as 'stable' - I don't think that > it has 'officially' been designated so. Actually, 2.3.11 is stable as of 10/18. Bowie

2 1

Re: [CentOS] why was LILO removed from centOS 4.2?
by Brian T. Brunner 30 Nov '05

30 Nov '05

The question remains unanswered: WHY was LILO removed? We/you/they removed *something that works*. What took its place does not work everywhere LILO does... a functionality loss. I hear folks saying "that loss is corrected in a future release" That's saying GRUB is *almost* ready to replace LILO, which has been removed prematurely. The question was "Hey, REDHAT, *WHY*?" Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> mail-lists(a)karan.org 11/30/05 10:55AM >>> Nielsen, Steve wrote: > I meant not a visible choice by default :). > > Thanks for the tip. I was not aware of making it visible in that way. > > So at the prompt you type: > > "boot: lilo" ? > boot: linux lilo - K _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

4 3

RE: [CentOS] Building rpms
by Bowie Bailey 30 Nov '05

30 Nov '05

From: Johnny Hughes [mailto:mailing-lists@hughesjr.com] > On Wed, 2005-11-30 at 11:28 -0500, Matt Hyclak wrote: > > On Wed, Nov 30, 2005 at 11:16:08AM -0500, Bowie Bailey enlightened us: > > > From: Matt Hyclak [mailto:hyclak@math.ohiou.edu] > > > > > > > > On Wed, Nov 30, 2005 at 11:05:48AM -0500, Bowie Bailey enlightened us: > > > > > > > > > > I found an rpm from Fedora Core Development on RPMFIND. Will this one work > > > > > with Centos, or should I grab the source rpm and rebuild it? > > > > > > > > Rebuild from src.rpm. > > > > > > Ok, tried that... > > > > > > $ rpmbuild --rebuild openldap-2.3.11-3.src.rpm > > > Installing openldap-2.3.11-3.src.rpm > > > error: Failed build dependencies: > > > bind-libbind-devel is needed by openldap-2.3.11-3.x86_64 > > > libtool-ltdl-devel is needed by openldap-2.3.11-3.x86_64 > > > > > > Where do I find these two? Do they have different names with CentOS, > > > or do I have to get them from elsewhere? > > > > > > Thanks, > > > Bowie > > > > You'll probably have to get them from the FC Development repository as well. > > You're probably looking at the bind and libtool srpms, if I had to guess. > > If you're lucky, those two won't depend on too much else, otherwise you'll > > spiral quickly into dependency hell. > > > > > What is the purpose of the LDAP upgrade ... if it is security you are > worried about ... those get in there. > > See this: > http://www.redhat.com/advice/speaks_backport.html > > When you start changing major components, you greatly reduce the > stability of CentOS for yourself ... and you ruin the system > interoperability. The purpose is extra features. Mainly, we are having problems with reliability. Twice now, when the system has crashed, the database was corrupted. The scary thing is that both times the database was completely idle when this happened. Version 2.3 fixes a problem with the database checkpoint command and also allows for an automatic database recover on startup. Hopefully, this will at least allow us to recover more easily in the case of a crash. We are also looking at updating Berkely DB to see if that would help. Bowie

1 0

RE: [CentOS] Building rpms
by Bowie Bailey 30 Nov '05

30 Nov '05

From: Matt Hyclak [mailto:hyclak@math.ohiou.edu] > > On Wed, Nov 30, 2005 at 11:05:48AM -0500, Bowie Bailey enlightened us: > > > > I found an rpm from Fedora Core Development on RPMFIND. Will this one work > > with Centos, or should I grab the source rpm and rebuild it? > > Rebuild from src.rpm. Ok, tried that... $ rpmbuild --rebuild openldap-2.3.11-3.src.rpm Installing openldap-2.3.11-3.src.rpm error: Failed build dependencies: bind-libbind-devel is needed by openldap-2.3.11-3.x86_64 libtool-ltdl-devel is needed by openldap-2.3.11-3.x86_64 # yum install bind-libbind-devel libtool-ltdl-devel Setting up Install Process Setting up repositories update 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Parsing package install arguments No Match for argument: bind-libbind-devel No Match for argument: libtool-ltdl-devel Nothing to do Where do I find these two? Do they have different names with CentOS, or do I have to get them from elsewhere? Thanks, Bowie

4 3

gdb segfault under ddd
by Michael Ubell 30 Nov '05

30 Nov '05

I am using CentOS 4 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) GNU DDD 3.3.9 (x86_64-redhat-linux-gnu) I bring up ddd on a program compiled -g and type: list function_name gdb seg faults. If I bring up ddd on gdb and then run gdb with the same program an type list function_name everything works just fine.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss