https://bugzilla.suse.com/show_bug.cgi?id=1205452
Bug ID: 1205452 Summary: Running zypper dup -l in Leap 15.5 freezes GUI Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs@suse.de Reporter: non.space.1@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: ---
Further issues with Leap 15.5 yesterday morning . . . running 184 packages via console app . . . GUI "froze" so that I couldn't use the browser while the upgrades were running, and that process was also very slow. Mouse was operational. I was about to cancel out of the upgrade, when the last 10 or 15 packages went through. Followed by another long episode with "grub2" before the cursor returned. But, I couldn't get the Terminal app to "come up" to run further commands, so I logged into TTY1 . . . .
In the TTY I ran "sudo update-bootloader" . . . also very slow and then shutdown. On cold boot Leap is first up in grub and several minutes went by with the black "Leap" screen and the spiral "activity" wheel . . . did not get to log in screen. I shut it down again. Second cold boot everything went quickly and now back in Leap GUI to type this out . . . .
Not sure if this is the "aging cpu" that is intermittently causing a slow down . . . or something in the Leap upgrade that was messing around with the GUI. There was a new kernel listed in the packages . . . .
For a rough comparison, today, booted in Deb Sid there were 190 packages to upgrade . . . machine handled them quickly and I was able to use the GUI and check browser while the upgrades were going on . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c1
--- Comment #1 from Fritz Hudnut non.space.1@gmail.com --- Back in TW today zypper running 247 packages . . . ran through fast and no problems with using GUI while running the update as was the case with Leap 15.5 the other day. Same machine . . . same drive. SSD sata.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c2
--- Comment #2 from Fritz Hudnut non.space.1@gmail.com --- Back in Leap 15.5 today and running zypper dup -l repeats the reported behavior . . . in console app. 77 packages were upgraded but leaving GUI frozen, again.
Had to shut down with the power button. Cold boot and the GUI is again working.
https://bugzilla.suse.com/show_bug.cgi?id=1205452
Chenzi Cao chcao@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Other |libzypp Assignee|screening-team-bugs@suse.de |zypp-maintainers@suse.de
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c3
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |non.space.1@gmail.com Flags| |needinfo?(non.space.1@gmail | |.com)
--- Comment #3 from Michael Andres ma@suse.com --- @Fritz could you please attach the /var/log/zypper.log (or an older and compressed /var/log/zypper.log-YYYYMMDD.xz) that shows the dup.
To see the execution dates and zypper commands included in a zypper LOGFILE you can install the zypper-log package and execute: zypper-log -l LOGFILE
This issue is hard to hunt. If zypper itself would somehow cause this slowless, I would expect it to occur together with other install commands and on other systems as well. By now we do not have other reports like this.
If it happens more often, maybe you can figure out if it occurs together with the update of a specific package. I will check the logs, maybe they reveal something.
If it occurs again, please try running `free` and/or `ps vax` to be sure you're not close to running out of memory. `top` might help to find processes running wild and eating the CPU power. `dmesg` output may also contain a hint.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c4
--- Comment #4 from Fritz Hudnut non.space.1@gmail.com --- Michael:
Thanks for the reply . . . zypper-log was apparently already installed, but running your command brought back "nothing found"??
I opened the /var/log/zypper.log and it showed a bunch of data from the 21st, tried to attach it and the server could not complete the action?? Tried it twice.
I'll try again later . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c5
--- Comment #5 from Fritz Hudnut non.space.1@gmail.com --- Trying again later to browse the zypper.log.xxxxx.xz file AND just the plain zypper.log to attach them to the report have "failed" . . . "internal server error" . . . "chameleon not found"????
I'll try at some later date . . . . Possibly I'm exceeding my skill level to get this log file attached to the bug report???? Seems like if I can navi to the file, I then should be able to browse it through the bug report attach function and . . . attach it???
Doesn't seem to be working . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c6
--- Comment #6 from Michael Andres ma@suse.com --- @Fritz, maybe the file is too big. Bugzilla AFAIK has a 10M limit for uploads.
If that's the reason, you can use `split` to cut the file into pieces. Then it should be possible to attach each part individually via the `Add an attachment` link abobe yout initial description.
To spit the file:
cd /tmp cat /var/log/zypper.log | gzip | split -b 10M --additional-suffix=-zypper.log.gz
The created pieces will be named like this:
xaa-zypper.log.gz xab-zypper.log.gz xac-zypper.log.gz ...
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c7
--- Comment #7 from Fritz Hudnut non.space.1@gmail.com --- @Michael:
I don't think it's the size of it, the log itself was something like 1.6MB and the compressed file was perhaps 132KB?? It''s a fairly new install.
One other thing I noticed is that "I" don't have permission to open the file(s) by just clicking on them . . . I could "cat" the log file and look at it in the console . . . .
Something else likely at work in the refusal to upload the file . . . but I can post here. It's prolly too big to copy/paste it here in a window . . . .
Forgotten now what the other way to move a file to a site and then put the link here?? [old guy stuff]
Might be on the other side of T-day to mess with it now . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c8
--- Comment #8 from Michael Andres ma@suse.com --- Not sure if I understood you correctly. Maybe a permission issue:
# ls -l /var/log/zypper.log -rw-r----- 1 root root <SIZE> <DATE> /var/log/zypper.log ^^^ (u)ser (AKA owner) permission ^^^ (g)roup permission ^^^ (o)thers permission
Per default the logfile has 'rw' permission for user 'root' (only 'r'ead permission for group 'root') and no permission for other users. If you are logged in as an 'ordinary' user your browser may indeed not be allowed to read the file. If you can 'cat' the file, then this shell is running as user 'root'. You can check this by using the 'id' command:
# id uid=0(root) gid=0(root) groups=0(root)
As user 'root' you are the owner of the file and you can grant read access to other users by using 'chmod' (adding (+r)ead permission for (o)thers):
# chmod o+r /var/log/zypper.log
Check it wit 'ls'; the additional 'r' indicates read access for other users:
# ls -l /var/log/zypper.log -rw-r--r-- 1 root root <SIZE> <DATE> /var/log/zypper.log
Now you should be able to access the file from within your browser.
(After some while the system may reset the permission to it's default. If you want to do this manually after you uploaded the file: 'chmod o-r /var/log/zypper.log')
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c9
Fritz Hudnut non.space.1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(non.space.1@gmail | |.com) |
--- Comment #9 from Fritz Hudnut non.space.1@gmail.com --- Created attachment 863127 --> https://bugzilla.suse.com/attachment.cgi?id=863127&action=edit recent /var/log/zypper.log
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c10
--- Comment #10 from Fritz Hudnut non.space.1@gmail.com --- Michael Andres:
Thanks for the ownership hints . . . I did think that was why it was working, but didn't know how to change it in the terminal . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c11
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(non.space.1@gmail | |.com)
--- Comment #11 from Michael Andres ma@suse.com --- The log does no longer contain the dup from 2022-11-14 you mentioned in the initial description. The rotated log is probably still available as /var/log/zypper.log-yyymmdd.xz. The timestamp tells when the log was rotated, so it should be at or after 2022-11-14. `zypper log -l LOOGFILE` should be able to list the compressed log's content as well. So you can check whether it contains the dup in question.
The dup in the attached log has just 77 packages and is not suspicious. Apart perhaps of a long running grub2-branding-openSUSE-15.5.20220322-lp155.3.1 %posttrans script (~ 8min.). But I don't know the package, so I can't really tell whether this OK or not.
But maybe you can provide original dup log. And maybe you can attach the output of 'free -h' so we know how much memory is availale.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c12
--- Comment #12 from Fritz Hudnut non.space.1@gmail.com --- Michael A:
So, the only compressed file is from 11/21 ?? named zypper.log-20221121.xz and there is the "log file" which you say isn't showing much data.
The problem with the GUI "freezing" is still continuing . . . happened again last night, had to use the power button to shut it down.
It's not a RAM issue, machine has 16 GB RAM . . . and "free -h" supports that:
[CODE]# zypper log -l LOOGFILE ================================================================================ Collect from LOOGFILE ... No such file No files to collect! '/usr/sbin/zypper-log' exited with status 1
# zypper log -l LOGFILE ================================================================================ Collect from LOGFILE ... No such file No files to collect! '/usr/sbin/zypper-log' exited with status 1
# free -h total used free shared buff/cache available Mem: 15Gi 1.7Gi 13Gi 34Mi 1.1Gi 13Gi Swap: 14Gi 0B 14Gi
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c13
Fritz Hudnut non.space.1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(non.space.1@gmail | |.com) |
--- Comment #13 from Fritz Hudnut non.space.1@gmail.com --- Created attachment 863156 --> https://bugzilla.suse.com/attachment.cgi?id=863156&action=edit compressed zypper.log 20221121
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c14
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?
--- Comment #14 from Michael Andres ma@suse.com --- (In reply to Fritz Hudnut from comment #12)
[CODE]# zypper log -l LOOGFILE
Sorry, LOOGFILE was meant to be a placeholder for the real filename:
# zypper log -l zypper.log-20221121 |prefix
Collect from zypper.log-20221121 ...
TIME PID VER CMD 2022-10-21 17:11 2176 1.14.57 zypper ref 2022-10-21 17:12 2308 1.14.57 zypper dup -l 2022-10-21 17:32 15584 1.14.57 zypper dup -l 2022-10-24 07:44 6397 1.14.57 sudo zypper ref 2022-10-24 07:44 6428 1.14.57 sudo zypper dup -l 2022-10-30 17:39 2874 1.14.57 zypper ref 2022-10-30 17:40 3106 1.14.57 zypper dup -l 2022-10-30 17:52 10281 1.14.55 zypper ref 2022-10-30 18:04 22102 1.14.55 zypper ref 2022-10-30 18:04 22132 1.14.55 zypper dup -l 2022-10-30 18:14 20743 1.14.55 zypper clean --all 2022-10-30 18:15 20786 1.14.55 zypper ref 2022-10-30 18:17 737 1.14.55 /usr/bin/zypper -n purge-kernels 2022-11-07 07:58 8738 1.14.55 zypper ref 2022-11-07 07:58 8768 1.14.55 zypper dup -l 2022-11-14 07:53 6526 1.14.55 sudo zypper ref 2022-11-14 07:53 6558 1.14.55 sudo zypper dup -l 2022-11-14 08:51 740 1.14.57 /usr/bin/zypper -n purge-kernels
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c15
--- Comment #15 from Fritz Hudnut non.space.1@gmail.com --- @Michael A:
Ah, OK . . . well I think I attached what I had . . . ??? Are we "up to date"??
Not sure if there is still a problem in Leap 15.5, I've been in and out of it a few times lately. Tried to run a zypper dup -l this morning, but "nothing to do" . . . so I don't know if the freezing GUI only happens after there is "something to do" or not???
Guess I'll post back if the problem remains . . . .
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c16
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? |
--- Comment #16 from Michael Andres ma@suse.com --- Created attachment 863319 --> https://bugzilla.suse.com/attachment.cgi?id=863319&action=edit Execution times of the install steps
2022-11-14 07:53 6558 1.14.55 sudo zypper dup -l
2022-11-14 07:53:54 - zypper start 2022-11-14 07:55:14 - install start 2022-11-14 08:18:17 - install end
So we have less than 2 min. for solving and downloading 184 packages.
23 min. for installing the packages, BUT only 2 actions took long: - 9 min for installing kernel-default-5.14.21-150500.34.1.x86_64 - 8 min for %posttrans of grub2-i386-pc-2.06-150500.15.1.noarch
The remaining 182 packages took 6 min. That's not too bad.
Whether kernel-default/grub2-i386-pc were responsible for the slow UI is something I cant tell. Both tasks are known to consume memory and CPU power, but this should not persist until reboot. The log at least contains no hint to a problem the installer had recognized. An by now We did not receive any similar reports.
The log lets me assume that you are using xfce? If that's right we can move the bug to the xfce maintainers. Maybe they have some more ideas on how to check the reason for the slow UI.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c17
--- Comment #17 from Fritz Hudnut non.space.1@gmail.com --- @Michael A:
It is XFCE that is running on the Leap 15.5 install . . . but thanks for the analysis and time spent on it. The problem did recur, hence the bug report, and it is a '12 era cpu, that possibly might be "befuddled" by more complex packages??
Grub has been "playing up" lately, I'm running a multi-boot situation on the machine and the recent grub2 "upgrades" have been causing problems with a number of my distros, don't know if that happened in my Leap install, which is supposed to be the master grub controller . . . but seems to have lost control of it?
Thanks for the attention to it . . . perhaps the XFCE devs might be able to find something???
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c18
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|libzypp |Xfce Assignee|zypp-maintainers@suse.de |bnc-team-xfce@forge.provo.n | |ovell.com Summary|Running zypper dup -l in |[XFCE] Running zypper dup |Leap 15.5 freezes GUI |-l in Leap 15.5 freezes GUI
--- Comment #18 from Michael Andres ma@suse.com --- Maybe the XFCE maintainers can help to figure out what slows down XFCE so badly.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c19
--- Comment #19 from Fritz Hudnut non.space.1@gmail.com --- Problem happened again this morning in Leap 15.5 . . . running "sudo update-bootloader" . . . takes several minutes to return cursor, not actually updating grub and then cursor box is showing as a rectangle . . . and mouse can mouse around, but clicking on stuff is non-responsive . . . .
Had to shut down using power button . . . and now back in Leap . . . to type this email.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c20
Maurizio Galli maurizio.galli@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maurizio.galli@suse.com
--- Comment #20 from Maurizio Galli maurizio.galli@suse.com --- Tumbleweed Xfce is fine for me and I am not able to reproduce the issue.
Unfortunately I don't have a chance to test Leap 15.5 on baremetal at the moment
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c21
Stefan Seyfried seife@novell.slipkontur.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |seife@novell.slipkontur.de
--- Comment #21 from Stefan Seyfried seife@novell.slipkontur.de --- Things I have seen in the past: Updates of font packages cause the X server to basically stall for quite some time, especially (this is a guess) on older/slower CPUs and graphics adapters.
This lead to display "hangs" of about a minute without content updates, don't remember if the mouse pointer still moved. A text console login showed, that the xorg processes were consuming lots of CPU. AFAIR the update process continued in the background, it was just no progress visible on the desktop.
I have not noticed this in recent times, but I'm now using a slightly newer / faster machine (only 10 years old core i5-3320M Thinkpad 430 ;-) instead of the old one before (13 years old core2 duo ulv Thinkpad x200s), and maybe now it is just the occasional "10 seconds hang" and no longer the "almost one minute hang" and I just don't notice it anymore.
So especially if this is an "older" machine where this happens, just waiting longer for it to finish would be my first option. In order to debug this, I would have a ready-logged-in text console handy and in case the GUI hangs would check if the last installed packages (should be visible in journal or with "rpm -qa --last|head" are font packages indeed.
I'm not sure who is "to blame" for this issue, if it is the X server dynamically reloading the changed fonts or the graphics toolkits, but that's a secondary question, once you find out it is actually the same problem I was seeing.
https://bugzilla.suse.com/show_bug.cgi?id=1205452 https://bugzilla.suse.com/show_bug.cgi?id=1205452#c22
--- Comment #22 from Fritz Hudnut non.space.1@gmail.com --- (In reply to Stefan Seyfried from comment #21)
Things I have seen in the past: Updates of font packages cause the X server to basically stall for quite some time, especially (this is a guess) on older/slower CPUs and graphics adapters.
This lead to display "hangs" of about a minute without content updates, don't remember if the mouse pointer still moved. A text console login showed, that the xorg processes were consuming lots of CPU. AFAIR the update process continued in the background, it was just no progress visible on the desktop.
So especially if this is an "older" machine where this happens, just waiting longer for it to finish would be my first option. In order to debug this, I would have a ready-logged-in text console handy and in case the GUI hangs would check if the last installed packages (should be visible in journal or with "rpm -qa --last|head" are font packages indeed.
I'm not sure who is "to blame" for this issue, if it is the X server dynamically reloading the changed fonts or the graphics toolkits, but that's a secondary question, once you find out it is actually the same problem I was seeing.
@maurizio:
OK, well, this is Leap 15.5 XFCE, whether the XFCE is relevant or not is another story . . . . I have several rolling tumbleweed based systems and no issues there on the same machine . . . . '12 cMP i7 4core
@stefan s:
Yes, in the long history of using XFCE, back to approx '07 or earlier, there has been issues of GUI "freezing" . . . in PPC based systems, etc. This is longer than 1 minute AND can not get to a TTY from with the freeze . . . .
-
bugzilla_noreply＠suse.com