Bug 975483 - xfce-panel acts weird after yum update
xfce-panel acts weird after yum update
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xfce4-panel (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-18 10:49 EDT by Jiri Pospisil
Modified: 2017-11-07 12:17 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 08:56:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Question window (1013.64 KB, image/png)
2013-06-18 10:50 EDT, Jiri Pospisil
no flags Details
Warning window (1016.45 KB, image/png)
2013-06-18 10:50 EDT, Jiri Pospisil
no flags Details
~/.xsession-errors (1.52 KB, text/plain)
2013-06-18 10:54 EDT, Jiri Pospisil
no flags Details
/var/log/yum.log (9.93 KB, text/x-log)
2013-06-18 10:54 EDT, Jiri Pospisil
no flags Details
~/.cache/sessions/xfce4-session-localhost.localdomain:0 (2.16 KB, text/plain)
2013-06-19 06:28 EDT, Jiri Pospisil
no flags Details
~/.config/xfce4/xfconf/ (49.63 KB, text/plain)
2013-06-24 06:16 EDT, Jiri Pospisil
no flags Details

  None (edit)
Description Jiri Pospisil 2013-06-18 10:49:24 EDT
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.
Comment 1 Jiri Pospisil 2013-06-18 10:50:10 EDT
Created attachment 762527 [details]
Question window
Comment 2 Jiri Pospisil 2013-06-18 10:50:43 EDT
Created attachment 762528 [details]
Warning window
Comment 3 Jiri Pospisil 2013-06-18 10:54:02 EDT
Created attachment 762529 [details]
~/.xsession-errors
Comment 4 Jiri Pospisil 2013-06-18 10:54:32 EDT
Created attachment 762530 [details]
/var/log/yum.log
Comment 5 Christoph Wickert 2013-06-18 12:04:56 EDT
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?
Comment 6 Kevin Fenzi 2013-06-18 12:26:36 EDT
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?
Comment 7 Jiri Pospisil 2013-06-19 06:28:56 EDT
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)
Comment 8 Kevin Fenzi 2013-06-21 17:03:29 EDT
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)
Comment 9 Jiri Pospisil 2013-06-24 06:16:13 EDT
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.
Comment 11 Kevin Fenzi 2013-06-25 15:49:30 EDT
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?
Comment 12 Jiri Pospisil 2013-06-26 07:39:10 EDT
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.
Comment 13 Kevin Fenzi 2013-06-28 14:58:16 EDT
Would you like to file the panel bug upstream? Or would you like me to do so?

Thanks for tracking this down...
Comment 15 Jiri Pospisil 2013-09-10 11:24:00 EDT
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.
Comment 16 rpickeri 2013-10-04 16:15:15 EDT
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?
Comment 17 Kevin Fenzi 2013-10-15 23:10:33 EDT
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?
Comment 18 Mazen Mardini 2013-11-11 10:15:44 EST
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.
Comment 19 Fedora End Of Life 2015-01-09 17:09:36 EST
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.
Comment 20 Fedora End Of Life 2015-02-18 08:56:51 EST
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.
Comment 21 Charlie Bennett 2017-11-07 12:17:07 EST
It's happening after an upgrade from Fedora 25 to Fedora 26

Note You need to log in before you can comment on or make changes to this bug.