Red Hat Bugzilla – Bug 975483
xfce-panel acts weird after yum update
Last modified: 2017-11-07 12:17:07 EST
Description of problem: I was following "QA:Testcase desktop updates" running freshly installed F19 TC3 using Xfce environment. After the yum update and reboot, xfce-panel didn't start. When I tried to open the panel settings (right click on desktop -> applications -> settings -> panel), a small question window appeared and asked me, if I wanted to run the xfce-panel. After I agreed, new notification window appeared and informed me, that the xfce panel is running in kiosk mode. After a reboot or logoff/login, the question window appears automatically. Version-Release number of selected component (if applicable): xfce4-panel-4.10.1-1.fc19.x86_64 How reproducible: Steps to Reproduce: 1. boot fedora 19 TC3 installation DVD 2. in software selection choose Xfce desktop + applications for xfce desktop + extra plugins for xfce panel + multimedia support for xfce + xfce office 3. complete the installation 4. install available updates via yum extender 5. reboot 6. login using an xfce session Actual results: 6. xfce panel doesn't start Expected results: 6. xfce panel starts normally Additional info: According to [1] kiosk mode can be defined in ${sysconfdir}/xdg/xfce4/kiosk/kioskrc, where ${sysconfdir} usually is /etc. I have no such configuration on that machine - the path /etc/xdg/xfce4/kiosk doesn't exist. Even wierder is the fact, that altough I am told that the panel runs in kiosk mode every time I start it, I can make changes in its preferences and those changes are preserved. Note: after subsequent reboots/logoffs, multiple question windows are displayed on xfce-session start.
Created attachment 762527 [details] Question window
Created attachment 762528 [details] Warning window
Created attachment 762529 [details] ~/.xsession-errors
Created attachment 762530 [details] /var/log/yum.log
According to xsession errors, there are 3 different applications (abrt, networkManager and polkit-gnome-authentication-agent) are complaining that dbus is not working. Could that be the root cause of the problem?
I wonder if your session got corrupted somehow when you did the orig reboot. Did you reboot via the logout/reboot menu/button? Can you attach your: ~/.cache/sessions/xfce-4-session* file?
Created attachment 762851 [details] ~/.cache/sessions/xfce4-session-localhost.localdomain:0 Yes, I did reboot via that menu button. Attaching the mentioned file. Dbus seems to be running: ----- # pgrep -l dbus 452 dbus-daemon 1561 dbus-launch 1562 dbus-daemon 1569 dbus-daemon ----- (this is prior to login)
Are there any poorly formed (full of 0's or binary) files in ~/.config//xfce4/xfconf/ ? I wonder if something in there got corrupted... If you make a new user do they behave as expected? (ie, is the problem system wide or per user)
Created attachment 764547 [details] ~/.config/xfce4/xfconf/ Attaching the contents of xfconf directory, it seems normal to me (no corrupted binary files). When logging into a newly created user account the problem doesn't appear, co it is not system-wide.
I'm puzzled. ;( I don't suppose theres any way you could do a clean install with the current rc and see if you can duplicate the problem there?
I tried to reproduce the issue in F19 RC2, but was unable to. I think it is not possible to reproduce the cause as it originally happenned. It could have been caused by some of the package upgrades or non-clean restart or something. But I was able to isolate the problematic user file. It is .cache/sessions/xfce4-session-localhost.localdomain:0. I think this is what happenned: I. Some package upgrade or not-exactly-clean logout caused that the session file was created, but information about the running instance of xfce4-panel was missing there. II. I logged in, the session was restored, but obviously without any running panel. III. I assumed, that if I open panel's preferences, it should be run automatically. IV. The panel preferences are run as "xfce4-panel --preferences". If no instance of the panel is running, the user is asked to run a new one. But if it is run this way, the panel for some reason thinks it is run in kiosk mode, although it is not. V. When I logged out, the current session was saved - together with "xfce4-panel --preferences", which makes the panel act weird in subsequent log-sessions. I think the panel run via its preferences shouldn't consider itself to be in kiosk mode (unless it is specified in the kiosk config file). It is quite easily reproducible: I. killall xfce4-panel II. xfce4-panel --preferences III. In the question window, click "Execute" ...and you shouldn't get any kiosk mode warning. It would also be advisable that if no panel was running and the user assumed it is a good idea to run it by opening its preferences and clicking "Execute", the newly created instance of the panel should be run just as "xfce4-panel" without any "--preferences". So if it gets saved to the session cache, there would be no questions about executing the panel in subsequent sessions.
Would you like to file the panel bug upstream? Or would you like me to do so? Thanks for tracking this down...
Hi, this is the same Jiri again, sorry for such late response, but at the time you asked I already left Red Hat and kinda forgot about this BZ. I think I'd rather have you posted the upstream bug(s), as I currently don't have spare time to track such things.
I installed Fedora 19 on my server Tues. and have updated it and installed Xfce4 using yum. When I open a xfce4 session over a xterm session via ssh (WinAxe) the window is not usable. Many of the options do not open or if they do when I click on them they disappear. Some of the errors displayed include: Thumbnailer failed calling getFlavors. (who makes up this stuff!!) This display does not support XFixes extensions. Compositing Manager disabled. Failed to connect to proxy. When I click on something the following is displayed (in part): Gdf_ERROR ** The program 'xfdesktop' received an X Windows error. This probably reflects an error in the program. The error was 'BadRequest' .... Serial 538 error_code 1 request_code 138 minor_code 34. Any suggestions?
I have no idea how WinAxe works... some kind of windows X server? I'd guess there's a connection problem or WinAxe isn't emulating things correctly? If you run your Xfce session in a vnc server and connect via a vnc client does it all work?
I can reproduce this bug. I've got exactly the same issue with a clean installation of Fedora 19. Fyi, this happened today. One week ago though, when I installed the system from the same DVD, on the same computer I didn't get any issues. However, one thing I remember doing different was that I removed the bottom panel (Panel 2). I didn't remove it on my lastest installation. This time I just updated the system and rebooted.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
It's happening after an upgrade from Fedora 25 to Fedora 26