Of late xterm has started to be really slow to fire up if I haven’t used it for a while. Initially it takes about 30 s to give me a prompt! Subsequent instances much faster. Then if I leave it for half an hour or so, same thing again: 30 s to prompt. My hardware is not to blame: processor Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz, RAM 72 GB with system on SSD-drive.
Any idea what can cause this?
Cheers,
gostal
For starters
You might want to be running a supported version of openSUSE.
Updates are no longer available after January 2019, almost half a year ago.
Upgrade to 15.1 this month when it officially launches and you shouldn’t have to worry about an upgrade again for another year and a half.
Aside from your machine running old, unsupported code,
You might run top or something else to see if anything else is running or might be exerting memory pressure.
The amount of RAM has little to do with system performance, various factors will alter available resources… eg. applications running, memory leaks, overloaded sub-systems, etc.
TSU
According to this page:
https://news.opensuse.org/2018/08/08/opensuse-leap-42-3-end-of-life-is-extended/
end of life is June, so yet another month …
Of course, I’ve been thinking about upgrading but this is a company machine and the OpenSuse guy in our support team has retired. The new guys favour Ubuntu which I just got installed on an older machine to see I can get used to it. If I can the future will be Ubuntu also on this machine but in the mean time the slow startup is annoying.
I’ll try top and see if it gives any clues.
I can add that also connecting to this machine via ssh from another machine is sluggish both the logging in and firing up the prompt.
Cheers,
gostal
I never had a problem with slow “xterm” startup. My best guess is a memory shortage. And yes, I saw that you have lots of memory. But maybe you are using it all.
You can try upgrading which is essentially a re-install of everything…
There are 2 guides, the Online Upgrade is for upgrading by simply re-configuring repositories
In summary, an Online Upgrade involves
https://en.opensuse.org/SDB:System_upgrade
An Offline Upgrade is also very easy.
https://en.opensuse.org/SDB:Offline_upgrade
If running in a virtual machine, you can point your Virtual Machine to an ISO instead of burning to optical disk.
Although the system upgrade is very easy, individual apps will likely require special attention, and I assume with 72GB of RAM you’re running some big Server apps.
TSU
I’m writing this on 42.3 with 16GB RAM. Xterm launched instantly. I hadn’t used it for quite some time, as I always have Konsole open.
> inxi -SGxxxC
System: Host: 00srv Kernel: 4.4.176-96-default x86_64 bits: 64 compiler: gcc v: 4.8.5 Desktop: KDE 3.5.10 tk: Qt 3.3.8c
info: kicker wm: kwin dm: N/A Distro: openSUSE Leap 42.3
CPU: Topology: Dual Core model: Intel Core i3-4150T bits: 64 type: MT MCP arch: Haswell rev: 3 L2 cache: 3072 KiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 24002
Speed: 3000 MHz min/max: 800/3000 MHz Core speeds (MHz): 1: 3000 2: 3000 3: 3000 4: 3000
Graphics: Device-1: Intel 4th Generation Core Processor Family Integrated Graphics vendor: Micro-Star MSI driver: i915
v: kernel bus ID: 00:02.0 chip ID: 8086:041e
Display: server: X.Org 1.18.3 driver: modesetting unloaded: fbdev,vesa alternate: intel resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel Haswell v: 4.3 Mesa 17.0.5 compat-v: 3.0 direct render: Yes
I don’t think anyone should ordinarily have any problem launching xterm instantly,
AFAIK it’s the only terminal app openSUSE provides which is minimal and without all the enhancements you’ll find in other terminal apps.
TSU
Thank for your input, guys!
top or rather htop didn’t give mucn. No heavy load on any of the cpu:s and only about 10 % of memory used.
I believe I found out what caused the problem, though: Firefox. I did have some five windows, some with many tabs scattered over the workspaces. I killed them all and things are now back to normal. I guess I’ll have to do some pruning among the Firefox windows and tabs.
Cheers,
gostal
I believe I found out what caused the problem, though: Firefox. I did have some five windows, some with many tabs scattered over the workspaces. I killed them all and things are now back to normal. I guess I’ll have to do some pruning among the Firefox windows and tabs.
No, that was only a temporary fix. System continued to deteriorate so right before I went on holiday in the beginning of July I decided to take the advice and do an upgrade to Leap 15.0 via zypper and planned to go on to 15.1 but although the upgrade went through it screwed up all of my logins and also sudo:
User unknown to the underlying ...
In Leap 42.3 it happened now and then that root authentication got screwed up so I couldn’t run yast graphically. The reason always was that some lines in a file having to do with pam/kerberos got written in the wrong order. [FONT=arial][size=3](I have made a note of which file it was and also the correct order of the lines but it’s at the office and not here.) Luckily sudo always worked so I could use yast on the command line and go in and hit edit and then without any modification save and the lines were written in the correct order but now I simply can’t get into the machine. I guess that if I boot the system from a USB-stick with a live distro I can access and edit relevant files under /etc. This is, however, something I have never done so I would be grateful for detailed instructions regarding what to do.
I have also started wondering if the SSD that holds the system has started to degrade. What can I do to check?
Cheers,
gostal
[/size][/FONT]
Personally,
I haven’t experienced any broken credentials and related logins for many years… I think that the last time I experienced that was somewhere around 13.2…
In each case though, I was able to fix by resetting the password…
Sometimes it didn’t work using YaST so had to do it by command line,
And if the root account itself was a problem (su or sudo), I remember I was still able to logout and login as root and then was able to re-apply the root password which fixed the problem (I could then logout and back in as a normal user and su or sudo again).
Don’t know if that is similar to what you’re experiencing,
If so, then after you upgrade to 15. and perhaps reboot a time or two to firmly lock in your changes, I wouldn’t expect you should see that problem again.
TSU
Maybe I wasn’t clear enough. All users, the local one, the LDAP authenticated one and root are inaccessible after the upgrade. I do believe I tried rebooting a few times, also tried TTY.
I also remember clear warnings about messing around in /etc/pam…, /etc/security… and hence my call for help.
I did make a thorough backup so perhaps the simplest thing is to reinstall once I’ve made sure the SSD is healthy.
Cheers,
gostal
Turns out that some files under /etc/pam.d got screwed up. See this post.
Cheers,
gostal](https://forums.opensuse.org/showthread.php/537030-No-access-after-upgrade-to-Leap-15!)
I guess that explains the problem.
Yes, it evidently explains why I could not log in at all. As the post explains I found a way to enable locally authenticated login but exactly in what way the /etc/pam.d-files got screwed up so they can be mended is still outstanding.
I meant to edit the previous post to say that the upgrade has solved the xterm issue but as nrickert replied I might as well do it here. However, although xterm is snappy again :)the upgrade brought with it a host of other problems:
Are these issues consequences of a shaky zypper upgrade method or is the case more or less the same for a fresh install?
Cheers,
gostal
That’s not a bug – it’s a feature.
Actually, I think it’s a misfeature. But you should be able to turn it off, as I have been doing since forever.
There should be an icon that looks like a clipboard. That’s in the system tray (normally bottom right of screen). It is the Icon for “klipper”. Right click on that, and select “Configure Clipboard” to get to the settings.
When I do that, the setting window open minimized, so I have find it. There’s a box “Save clipboard contents on exit”. Uncheck that box, and the copied password will disappear after your next logout and login again.
Oh, it’s a feature, is it? You could have fooled me. Yeah, misfeature, indeed! Thanks for the tip on Clipboard settings.
On another note; today I received a mail notification that the Mate menu bug has been assigned, so hopefully that will be fixed in the not too distant future.
Cheers,
gostal