hi,
I have been using the f12 (686) on a dell latitude e6500 laptop. This is my corporate workstation and so far it's working really nice. Everything works out of the box and configuring it to work with its docking station was very easy (much easier than expected). Great work! Thanks.
There is one little problem. Every now and then when I boot the laptop it kind of 'freezes' and a few minutes later it works as it should without any other problems. I can change to a virtual terminal and login there, but if I try to login graphically it will take me like 2 to 3 minutes to complete the process. I cannot see anything in the log files.
Like I said, it does not happen all the time nor it is really annoying, but I would like to find out why this is happening. In /var/log/messages I do not get any errors. How can I debug the gnome login process?
On 16/04/2010 11:52, Natxo Asenjo wrote:
hi,
I have been using the f12 (686) on a dell latitude e6500 laptop. This is my corporate workstation and so far it's working really nice. Everything works out of the box and configuring it to work with its docking station was very easy (much easier than expected). Great work! Thanks.
There is one little problem. Every now and then when I boot the laptop it kind of 'freezes' and a few minutes later it works as it should without any other problems. I can change to a virtual terminal and login there, but if I try to login graphically it will take me like 2 to 3 minutes to complete the process. I cannot see anything in the log files.
Like I said, it does not happen all the time nor it is really annoying, but I would like to find out why this is happening. In /var/log/messages I do not get any errors. How can I debug the gnome login process?
Issues with the host file can sometimes upset gnome, check the localhost, and make sure it is correct.
On Fri, Apr 16, 2010 at 12:52:28 +0200, Natxo Asenjo natxo.asenjo@gmail.com wrote:
There is one little problem. Every now and then when I boot the laptop it kind of 'freezes' and a few minutes later it works as it should without any other problems. I can change to a virtual terminal and login there, but if I try to login graphically it will take me like 2 to 3 minutes to complete the process. I cannot see anything in the log files.
You might want to check you disk drives using smartctl (in the smartmontools package). If you have some bad blocks, they could cause probelms.
On that time interval I would suspect either dns timeouts or lots of disk activity as what you are waiting on.
On Fri, Apr 16, 2010 at 6:48 PM, Bruno Wolff III bruno@wolff.to wrote:
On Fri, Apr 16, 2010 at 12:52:28 +0200, Natxo Asenjo natxo.asenjo@gmail.com wrote:
There is one little problem. Every now and then when I boot the laptop it kind of 'freezes' and a few minutes later it works as it should without any other problems. I can change to a virtual terminal and login there, but if I try to login graphically it will take me like 2 to 3 minutes to complete the process. I cannot see anything in the log files.
You might want to check you disk drives using smartctl (in the smartmontools package). If you have some bad blocks, they could cause probelms.
I thought about that :) ; according to pamlipsest the disk is healthy and has passed all tests.
On that time interval I would suspect either dns timeouts or lots of disk activity as what you are waiting on.
the dns setup both at home as at work is solid (I'm a sysadmin, so yes, I know). I fail to see how dns should have local graphical logins slow down randomly, to be honest. Could you care to ellaborate?
As to disk i/o, nope, it's nearly non-existent. I can logon a vt and start top and the system is idle.
Any other ideas?
tia,
Like I said, it does not happen all the time nor it is really annoying, but I would like to find out why this is happening. In /var/log/messages I do not get any errors. How can I debug the gnome login process?
Issues with the host file can sometimes upset gnome, check the localhost, and make sure it is correct.
I see no strange things in the hosts file, just the anaconda stuff.
thanks.
On Sat, 2010-04-17 at 12:08 +0200, Natxo Asenjo wrote:
I fail to see how dns should have local graphical logins slow down randomly, to be honest. Could you care to ellaborate?
Because the display, even when on the same machine, is still handled as server and client, using hostnames for the networking. A change of names or addresses, mid-use, can be a bit of a pain, too.
On Sat, Apr 17, 2010 at 12:29 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2010-04-17 at 12:08 +0200, Natxo Asenjo wrote:
I fail to see how dns should have local graphical logins slow down randomly, to be honest. Could you care to ellaborate?
Because the display, even when on the same machine, is still handled as server and client, using hostnames for the networking. A change of names or addresses, mid-use, can be a bit of a pain, too.
fair enough, but if that were the case here, I would have this problem everythime, and that is not the case.
Thanks for your insight.
On 04/17/2010 06:29 PM, Tim wrote:
On Sat, 2010-04-17 at 12:08 +0200, Natxo Asenjo wrote:
I fail to see how dns should have local graphical logins slow down randomly, to be honest. Could you care to ellaborate?
Because the display, even when on the same machine, is still handled as server and client, using hostnames for the networking. A change of names or addresses, mid-use, can be a bit of a pain, too.
It is worth mentioning that if one is running sendmail that under certain circumstances and depending on the configuration the boot process will appear to freeze for some time when DNS requests are not being resolved.
One can easily determine if their system may suffer this fate by booting their system with the network disconnected.
On my F12 virtual system, it will present the login screen in 1:20 with the network connected, and 2:31 when the network is disconnected.
I do think the OP is talking about boot time and certainly the network status can influence that.
Tim:
Because the display, even when on the same machine, is still handled as server and client, using hostnames for the networking. A change of names or addresses, mid-use, can be a bit of a pain, too.
Natxo Asenjo:
fair enough, but if that were the case here, I would have this problem everythime, and that is not the case.
I'd expect that, too. However, do you sometimes find the computer thinks it's localhost.localdomain, and other times has a real domain/host name?
One possible cause for *sometimes* having problems like this, rather than consistent problems, can be having two DHCP servers on a LAN (such as a modem/router as well as something else), with one properly doling out addresses, another improperly doing so, and occasional clashes between them.
On Sat, Apr 17, 2010 at 12:08:51 +0200, Natxo Asenjo natxo.asenjo@gmail.com wrote:
the dns setup both at home as at work is solid (I'm a sysadmin, so yes, I know). I fail to see how dns should have local graphical logins slow down randomly, to be honest. Could you care to ellaborate?
I am not sure what the mechanism would be. But the delay period suggests dns as one possible cause. But it could be a network timeout waiting on some other service as well. It's just that dns is the most common thing to be waiting on when you see this.
As to disk i/o, nope, it's nearly non-existent. I can logon a vt and start top and the system is idle.
Any other ideas?
Maybe telnet into the machine from elsewhere before X is running and either use startx or telinit to start up X and then take a look around. Maybe disk activity spikes then. Maybe you can spot an unexpected network connection attempt.
hi,
I have only one dhcp server on my lan. The laptop has always a good dns name (at home or at work, it has records in both zones).
I remember having something similar quite a while ago (2 years ago) with debian systems and my solution was disabling the avahi-daemon.
I have done that here, we'll see how it goes.
Thanks for your input!
2010/4/16 Natxo Asenjo natxo.asenjo@gmail.com:
hi,
I have been using the f12 (686) on a dell latitude e6500 laptop. This is my corporate workstation and so far it's working really nice. Everything works out of the box and configuring it to work with its docking station was very easy (much easier than expected). Great work! Thanks.
There is one little problem. Every now and then when I boot the laptop it kind of 'freezes' and a few minutes later it works as it should without any other problems. I can change to a virtual terminal and login there, but if I try to login graphically it will take me like 2 to 3 minutes to complete the process. I cannot see anything in the log files.
Like I said, it does not happen all the time nor it is really annoying, but I would like to find out why this is happening. In /var/log/messages I do not get any errors. How can I debug the gnome login process? -- Groeten, Natxo Asenjo
I had a similar problem until recently with F12 (and previously F11). But in my case it took EVERY TIME additional 40 seconds before I could login. This system boots in runlevel 3 and I do startx when I need GUI. So, actually this delay occurred just after all daemons have been started and during login process. Playing around with services I've found it was preload installed a while ago who caused a lot of disk IO usage. Disabling it resulted in a faster boot process (with no delay at the end of it) and less memory usage on a booted system. But now X takes about two times slower than before...
On Sat, 2010-04-17 at 16:13 +0200, Natxo Asenjo wrote:
I have only one dhcp server on my lan. The laptop has always a good dns name (at home or at work, it has records in both zones).
And that last tidbit of information might be the crucial bit, that you're using one computer on two different networks.
I remember having something similar quite a while ago (2 years ago) with debian systems and my solution was disabling the avahi-daemon.
Yes, no point having that if you don't need it. Throwing another address assignment scheme in the mix might be a problem, under some circumstances. (It certainly was for some people, where the DHCP server was so slow in assigning an address that the machine gave itself an address, in the meantime, one that precluded full networking).
On Tue, 20 Apr 2010 02:59:55 +0930 Tim wrote:
I have only one dhcp server on my lan. The laptop has always a good dns name (at home or at work, it has records in both zones).
And that last tidbit of information might be the crucial bit, that you're using one computer on two different networks.
That could be an issue. I'm pretty sure fedora stashes the IP it got from DHCP the last time, and says "Oh! Pretty Please give me this IP again!" when it connects again. If that IP isn't available or is on the wrong subnet or something it might take longer to sort things out (just a random possibility - I don't know that I've ever seen this cause a big delay).
On Mon, Apr 19, 2010 at 7:29 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2010-04-17 at 16:13 +0200, Natxo Asenjo wrote:
I have only one dhcp server on my lan. The laptop has always a good dns name (at home or at work, it has records in both zones).
And that last tidbit of information might be the crucial bit, that you're using one computer on two different networks.
well, that's what laptops are for, right? :)
Anyway, all laptop users use dhcp all the time, this should not be the cause of the delay.