On Thu, Feb 5, 2015 at 3:56 AM, John Andersen 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 Thu, Feb 5, 2015 at 2:00 PM, Anton Aylward 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

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 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 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