[opensuse] Several new and older 13.2 suddenly taking a minute or more after password entered in ssh login, same with su -
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user. One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines. What? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Figured out something more that it is behaving like this when the machine has been rebooted as soon as the network comes up and the sshd already takes the login apparently some other services are still missing or stalling or taking time until the machine can complete the login properly. When i wait for more minutes after the machine reboot the login is speedy and pretty much normal. Is this some udevd side effects or parallel boot process method and such? Thanks. On Thu, Feb 5, 2015 at 1:42 AM, cagsm <cumandgets0mem00f@gmail.com> wrote:
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines.
What? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On February 4, 2015 4:47:42 PM PST, cagsm <cumandgets0mem00f@gmail.com> wrote:
Figured out something more that it is behaving like this when the machine has been rebooted as soon as the network comes up and the sshd already takes the login apparently some other services are still missing or stalling or taking time until the machine can complete the login properly. When i wait for more minutes after the machine reboot the login is speedy and pretty much normal. Is this some udevd side effects or parallel boot process method and such? Thanks.
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su
On Thu, Feb 5, 2015 at 1:42 AM, cagsm <cumandgets0mem00f@gmail.com> wrote: -
ing on these machines.
What?
Dispensing with your top posting.... Do you have any cloud storage applications running such as Dropbox or some such that takes a while and a bunch of bandwidth to verify that it is synced? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Feb 5, 2015 at 3:56 AM, John Andersen <jsamyth@gmail.com> wrote:
Dispensing with your top posting.... Do you have any cloud storage applications running such as Dropbox or some such that takes a while and a bunch of bandwidth to verify that it is synced?
No these are simple mostly clean installs of default opensuse 13.2. Nothing fancy. I can absolutely repro this stuff, upon reboot of the machine, the sshd already takes in the login attempt and accepts password or at least waits after entering it and then takes a minute or so, and even dns (other poster) cant be a problem I think as my remote location and ip doesnt change and has proper forward and reverse dns set, but I might try that other dns setting. I also tried from two distinct remote locations to log in and to debug this stuff a bit. Upon reboot it always takes long and even after login the su - command takes long as well. But when I wait some more minutes before I even initially attempt to ssh inwards, then everything is speedy and quickly as usual. So there is something at the very beginning at boot time that hinders and makes the logon process stall. What seems odd to me that even the su - is stalled, where is dns lookup in that stage or anything?? Also no remote filesystems or anything on the box. Simple desktop box default opensuse install. I think I remember these kind of stalls from at leat a year back or even longer every now and then but I never made the connection to the reboot the machines just had before during occasions, but this time i figured it out that it was reboot related. maybe someone else can repro this odd behavior as well. thanks anyways odd and weird stuff experiencing as a users to linux or better say opensuse. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/05/2015 04:10 AM, cagsm wrote:
But when I wait some more minutes before I even initially attempt to ssh inwards, then everything is speedy and quickly as usual. So there is something at the very beginning at boot time that hinders and makes the logon process stall.
It occurs to me that something this specific is, as John suggests, due to waiting for other, probably network, services to complete start-up. if it is about processes started at logup you might want to make use of the systemd tools that analyse the sequence of start-up processes and how long they take. I may simply be that - an order or dependency. It may also be a configuration. I see a difference in performance of Firefox if I use dnsmasq rather than BIND. It only occurs if I open a LOT of heavy graphics pages sequentially fast, such as a vendors collection at eBay where the pages have a lot of commona material. Maybe some cache problems. Still looking into it. Different problem from yours in the specific, but it does illustrate a point. What are *you* using for DNS? BIND or dnsmasq? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Feb 5, 2015 at 2:00 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
It may also be a configuration. I see a difference in performance of Firefox if I use dnsmasq rather than BIND. It only occurs if I open a LOT of heavy graphics pages sequentially fast, such as a vendors collection at eBay where the pages have a lot of commona material. Maybe some cache problems. Still looking into it. Different problem from yours in the specific, but it does illustrate a point. What are *you* using for DNS? BIND or dnsmasq?
what do you mean? this is a desktop client machine, it uses external dns or that internal nscd or whatever thats inside the linux libraries. no bind or stomthing. it is not a dns server. it uses external dns servers. whatever. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/05/2015 08:18 AM, cagsm wrote:
On Thu, Feb 5, 2015 at 2:00 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
It may also be a configuration. I see a difference in performance of Firefox if I use dnsmasq rather than BIND. It only occurs if I open a LOT of heavy graphics pages sequentially fast, such as a vendors collection at eBay where the pages have a lot of commona material. Maybe some cache problems. Still looking into it. Different problem from yours in the specific, but it does illustrate a point. What are *you* using for DNS? BIND or dnsmasq?
what do you mean? this is a desktop client machine, it uses external dns or that internal nscd or whatever thats inside the linux libraries. no bind or stomthing. it is not a dns server. it uses external dns servers. whatever.
Desktops can certainly benefit from a local caching DNS service, especially one that caches across reboots. My desktop doesn't need to be a DNS server in any traditional sense to benefit from a machine local instance of dnsmasq. Of course to feel that benefit you'll need to make sure the first in /etc/resolv.conf is 127.0.0.1. If, as others in this tread argue, it is a DNS issue, that this is one avenue you may find efficacious. Either way, it is of value. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello! Am 05.02.2015 um 15:38 schrieb Anton Aylward:
On 02/05/2015 08:18 AM, cagsm wrote:
On Thu, Feb 5, 2015 at 2:00 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
It may also be a configuration. I see a difference in performance of Firefox if I use dnsmasq rather than BIND. It only occurs if I open a LOT of heavy graphics pages sequentially fast, such as a vendors collection at eBay where the pages have a lot of commona material. Maybe some cache problems. Still looking into it. Different problem from yours in the specific, but it does illustrate a point. What are *you* using for DNS? BIND or dnsmasq?
what do you mean? this is a desktop client machine, it uses external dns or that internal nscd or whatever thats inside the linux libraries. no bind or stomthing. it is not a dns server. it uses external dns servers. whatever.
Desktops can certainly benefit from a local caching DNS service, especially one that caches across reboots.
My desktop doesn't need to be a DNS server in any traditional sense to benefit from a machine local instance of dnsmasq. Of course to feel that benefit you'll need to make sure the first in /etc/resolv.conf is 127.0.0.1.
If, as others in this tread argue, it is a DNS issue, that this is one avenue you may find efficacious. Either way, it is of value.
I had this very effect also a few times. Especially after an update of the dbus package. It turned out that freedesktop.login1 service timed out at boot. I did systemctl restart dbus-org.freedesktop.login1.service and all was back to normal. I haven't figured out why it times out until now. HTH --Tom -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/02/15 13:47, cagsm wrote:
Figured out something more that it is behaving like this when the machine has been rebooted as soon as the network comes up and the sshd already takes the login apparently some other services are still missing or stalling or taking time until the machine can complete the login properly. When i wait for more minutes after the machine reboot the login is speedy and pretty much normal. Is this some udevd side effects or parallel boot process method and such? Thanks.
On Thu, Feb 5, 2015 at 1:42 AM, cagsm <cumandgets0mem00f@gmail.com> wrote:
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines.
What?
If you haven't already, you might try uncommenting the line in /etc/ssh/sshd_config in the remote machine(s) that reads #UseDNS=yes to make it read UseDNS=no, and restart the sshd service. This disables "reverse DNS lookup", I'm told. Anyway, it works here. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
cagsm wrote:
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines.
What?
DNS failures? Reverse lookup problems? -- Per Jessen, Zürich (-2.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/05/2015 01:42 AM, cagsm wrote:
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines.
What?
I think I already noticed this sometimes with 13.1 IIRC. The problem was even on tty1, but interestingly only for ordinary users, i.e., not for the root user. I didn't find out what the problem was, and now it's gone on all of my systems. but my guess was that the login process didn't get a systemd-session before the system wasn't fully up. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/05/2015 06:02 AM, Bernhard Voelker wrote:
On 02/05/2015 01:42 AM, cagsm wrote:
Very odd, as of today two more boxes or even more started to behave oddly when logging in via ssh from remote locations. Entering username then quickly able to enter the password and hitting enter then stalls the login process for maybe a minute or even longer until the default tcsh or bash or something terminal is available and greeting the user.
One machine is brand new 13.2 with latest updates applied. All of my 13.2 machines now behave this way. Same delay is experienced when su - ing on these machines.
What?
I think I already noticed this sometimes with 13.1 IIRC. The problem was even on tty1, but interestingly only for ordinary users, i.e., not for the root user. I didn't find out what the problem was, and now it's gone on all of my systems. but my guess was that the login process didn't get a systemd-session before the system wasn't fully up.
Have a nice day, Berny
I wonder if you and Cagsm are using Desktop Search options (Baloo and friends) for these accounts that you initially ssh into? Upon each user logging in, Baloo seems to check to see if files need indexing, but usually this does not take much time, and certainly doesn't impose much load. Also wondering if this happened on the SECOND ssh login to these machines? (If so you could ssh in once, become root tail the logs ( journalctl -ef ) then watch while you ssh in again to see any messages. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Bernhard Voelker -
cagsm -
John Andersen -
Per Jessen -
Robin Klitscher -
Tom Bühlmann