Hi,
Is it me or is CentOS 5 faster than FC6? I just switched and it seems that CentOS 5 loads faster and overall feels snappier. Could Red Hat have optimzed EL more than Fedora?. Just curious.
I really like what I see with CentOS 5. The devs have done a great job making a profesisonal looking distro. An of course kudos to Red Hat for all the engineering and for making the SRPMS available.
Paul
I have also noticed this. I have not yet run CentOS 5 but have been running RHEL5 for a month or so and it appears that after some time I cannot open applications in the GUI? Even simple ones like a terminal won't open. The task bar shown the application as "starting...." and the mouse goes into "busy mode", then after a minute or so the application starting goes away and the mouse goes back to the normal state. ?? I will have to see if I can get a machine running CentOS 5 and see if the issue is there too.
A. Darling
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Paul Vandenberg Sent: Thursday, March 22, 2007 5:31 AM To: centos@centos.org Subject: [CentOS] CentOS 5 Beta Feels Snappier
Hi,
Is it me or is CentOS 5 faster than FC6? I just switched and it seems that CentOS 5 loads faster and overall feels snappier. Could Red Hat have optimzed EL more than Fedora?. Just curious.
I really like what I see with CentOS 5. The devs have done a great job making a profesisonal looking distro. An of course kudos to Red Hat for all the engineering and for making the SRPMS available.
Paul _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 22/03/07, Aron.Darling@emulex.com Aron.Darling@emulex.com wrote:
I have also noticed this. I have not yet run CentOS 5 but have been running RHEL5 for a month or so and it appears that after some time I cannot open applications in the GUI? Even simple ones like a terminal won't open. The task bar shown the application as "starting...." and the mouse goes into "busy mode", then after a minute or so the application starting goes away and the mouse goes back to the normal state. ?? I will have to see if I can get a machine running CentOS 5 and see if the issue is there too.
I don't tend to bother with GUIs but is there a possibility the applications are opening on different virtual desktops? Can you see them running with a 'ps uxw' ?
If you can't even get a terminal to check, switch to a VTY with CTRL-ALT-F1 (switch back with CTRL-ALT-F8), login and run your ps from there.
Will.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Are you, by any chance, running tmpwatch ? I have seen this kind of thing happening on other distros. tmpwatch would remove files from /tmp related to X11 autentication, so the application would start, but X11 would not allow it to open.
Best Regards,
On Thu, Mar 22, 2007 at 08:34:16AM -0700, Aron.Darling@Emulex.Com wrote:
I have also noticed this. I have not yet run CentOS 5 but have been running RHEL5 for a month or so and it appears that after some time I cannot open applications in the GUI? Even simple ones like a terminal won't open. The task bar shown the application as "starting...." and the mouse goes into "busy mode", then after a minute or so the application starting goes away and the mouse goes back to the normal state. ?? I will have to see if I can get a machine running CentOS 5 and see if the issue is there too.
A. Darling
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Paul Vandenberg Sent: Thursday, March 22, 2007 5:31 AM To: centos@centos.org Subject: [CentOS] CentOS 5 Beta Feels Snappier
Hi,
Is it me or is CentOS 5 faster than FC6? I just switched and it seems that CentOS 5 loads faster and overall feels snappier. Could Red Hat have optimzed EL more than Fedora?. Just curious.
I really like what I see with CentOS 5. The devs have done a great job making a profesisonal looking distro. An of course kudos to Red Hat for all the engineering and for making the SRPMS available.
Paul _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On 3/22/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Are you, by any chance, running tmpwatch ? I have seen this kind of thing happening on other distros. tmpwatch would remove files from /tmp related to X11 autentication, so the application would start, but X11 would not allow it to open.
Thats evil. I had tmpwatch do similar things before. The solution was to train the app not to save log files (or in this case authentication credentials) to tmp. I really wonder if X11 on RHEL5 should be configured to store its credential type files elsewhere?
Cheers...james
P.S. The problem I had in the past was an app would open a log file, and some time later tmpwatch would delete it. The app though still had the fd open on the log and was still writting to it, such that space was being depleted in /tmp but there was no file you could see that was taking all the space. Furthermore any logrotation schemes just simply didn't work because there was no link associated with the file anymore.
Rodrigo Barbosa wrote:
Are you, by any chance, running tmpwatch ? I have seen this kind of thing happening on other distros. tmpwatch would remove files from /tmp related to X11 autentication, so the application would start, but X11 would not allow it to open.
Then either tmpwatch *or* X authentification would be really broken. hier(7) says explicitly that no application should expect files in /tmp to stay. And authentification cookies should be put into the users directory, not into /tmp (which AFAIR is the case).
Ralph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Mar 22, 2007 at 09:09:06PM +0100, Ralph Angenendt wrote:
Rodrigo Barbosa wrote:
Are you, by any chance, running tmpwatch ? I have seen this kind of thing happening on other distros. tmpwatch would remove files from /tmp related to X11 autentication, so the application would start, but X11 would not allow it to open.
Then either tmpwatch *or* X authentification would be really broken. hier(7) says explicitly that no application should expect files in /tmp to stay. And authentification cookies should be put into the users directory, not into /tmp (which AFAIR is the case).
I can see several xses-rodrigob.XXXXXX files on /tmp, along with files from ssh-agent, .X0-lock, .X11-unix, gconfd, orbit and others.
Yes, it is stupid, and should not be on /tmp. .X0-lock should be on /var/lock (or /var/run). .X11-unix should be on /var/run or /var/state. xses-rodrigob* should be on my home diretory (maybe .xsessions/). And so one and so forth.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On 3/22/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
Yes, it is stupid, and should not be on /tmp. .X0-lock should be on /var/lock (or /var/run). .X11-unix should be on /var/run or /var/state. xses-rodrigob* should be on my home diretory (maybe .xsessions/). And so one and so forth.
The x session files provide an interesting case, because many X apps will get angry if they're used over NFS, so any large-scale system (think ldap auth and automounted home dirs) would have issues. They should be somewhere not in /tmp, nor in /home. /var/tmp would potentially be a better place than /tmp
On Thu, 22 Mar 2007 16:20:31 -0400, Jim Perrin wrote:
On 3/22/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
Yes, it is stupid, and should not be on /tmp. .X0-lock should be on /var/lock (or /var/run). .X11-unix should be on /var/run or /var/state. xses-rodrigob* should be on my home diretory (maybe .xsessions/). And so one and so forth.
The x session files provide an interesting case, because many X apps will get angry if they're used over NFS, so any large-scale system (think ldap auth and automounted home dirs) would have issues. They should be somewhere not in /tmp, nor in /home. /var/tmp would potentially be a better place than /tmp
According to the default setup on CentOS4, tmpwatch seems also to clean up /tmp/var albeit less often than it does /tmp...
Akemi
Ralph Angenendt wrote:
Rodrigo Barbosa wrote:
Are you, by any chance, running tmpwatch ? I have seen this kind of thing happening on other distros. tmpwatch would remove files from /tmp related to X11 autentication, so the application would start, but X11 would not allow it to open.
Then either tmpwatch *or* X authentification would be really broken. hier(7) says explicitly that no application should expect files in /tmp to stay. And authentification cookies should be put into the users directory,
Doesn't that present problems with NFS?
Aron.Darling@Emulex.Com wrote:
I have also noticed this. I have not yet run CentOS 5 but have been running RHEL5 for a month or so and it appears that after some time I cannot open applications in the GUI? Even simple ones like a terminal won't open. The task bar shown the application as "starting...." and the mouse goes into "busy mode", then after a minute or so the application starting goes away and the mouse goes back to the normal state. ?? I will have to see if I can get a machine running CentOS 5 and see if the issue is there too.
I have seen this with FC6. It seems to manifest at random and it's quite rare. I think I've seen it with F7test as well.
Florin Andrei wrote:
It seems to manifest at random
Well, it appears to manifest more often on slower systems and/or when the machine is pretty busy.
Usually, I just click again the icon and it works fine.
-
Akemi Yagi -
Aron.Darling＠Emulex.Com -
Florin Andrei -
James Olin Oden -
Jim Perrin -
John Summerfield -
Paul Vandenberg -
Ralph Angenendt -
Rodrigo Barbosa -
Will McDonald