Bug 879922 - Fails to open from the Xfce menu.
Fails to open from the Xfce menu.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xfce4-panel (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
AcceptedNTH
:
: 879591 901577 994513 (view as bug list)
Depends On:
Blocks: F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-11-25 08:50 EST by Sergio
Modified: 2013-11-24 00:07 EST (History)
17 users (show)

See Also:
Fixed In Version: libxfce4ui-4.10.0-9.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-23 14:31:47 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 819275 None None None Never
GNOME Desktop 675789 None None None Never
Xfce 9626 None None None Never

  None (edit)
Description Sergio 2012-11-25 08:50:54 EST
Description of problem: Fedora 18 Beta RC1 Xfce spin live-cd.
'System-Config-Date' fails to open from the menu.
Adding 'StartupNotify=true' to system-config-date.desktop makes it work.

Version-Release number of selected component (if applicable):
1.10.2-1.fc18 (originally in the spin)
1.10.3-1.fc18 (updated)

Both behave the same way.

Additional info: similar to https://bugzilla.redhat.com/show_bug.cgi?id=879591 (although 'Users and Groups' work fine in the live environment)
Comment 1 Sergio 2012-12-08 10:09:41 EST
Running the final TC1 Xfce live-CD.
When trying to open system-config-date from the menu the CD spins just a little bit and ~/.xsession-errors registers:

Refusing to render service to dead parents.



Launching it from the command-line works.
Comment 2 Nils Philippsen 2012-12-12 08:36:06 EST
I've looked into this issue and it seems to come from double-forking in xfce-panel:

0) User launches system-config-date from xfce-panel (process P0)
1) P0 forks/clones into process P1
2) P1 forks/clones into process P2 and exits
3) P2 execs /usr/bin/system-config-date which is a script that execs pkexec with the actual program /usr/share/system-config-date/system-config-date.py as its argument
4) pkexec tries to find out info about its parent process (I guess to be able to keep authorizations around for a while) -- that parent process (P1) is gone by this time however. pkexec bails out then.

Here's an strace snippet outlining what happens (pids: P0: 4551, P1: 5223, P2: 5224):

--- 8< ---
nils@f18:~> strace -Ff -e clone,execve -p 4551
Process 4551 attached with 3 threads
[pid  4551] clone(Process 5223 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6e6a432c90) = 5223
[pid  5223] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6e6a432c90) = 5224
Process 5224 attached
[pid  5223] +++ exited with 0 +++
[pid  4551] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5223, si_status=0, si_utime=0, si_stime=0} ---
[pid  5224] execve("/usr/bin/system-config-date", ["/usr/bin/system-config-date"], [/* 51 vars */]) = 0
[pid  5224] execve("/usr/bin/pkexec", ["/usr/bin/pkexec", "/usr/share/system-config-date/sy"...], [/* 51 vars */]) = 0
[pid  5224] +++ exited with 127 +++
--- >8 ---

Bug #819275 documents a similar issue in GNOME shell, the patch for it can be found in the upstream bug at: https://bugzilla.gnome.org/show_bug.cgi?id=675789

Basically this patch adds G_SPAWN_DO_NOT_REAP_CHILD to the spawn flags and installs an empty child watch callback with g_child_watch_add() thereby avoiding double-forking. Changing component to xfce4-panel though it might belong to some other XFCE core component instead (but I wouldn't know which one).
Comment 3 Nils Philippsen 2012-12-12 08:54:35 EST
*** Bug 879591 has been marked as a duplicate of this bug. ***
Comment 4 Sergio 2012-12-12 12:21:39 EST
No pressure at all to answer this as it's just a personal question.
Wouldn't the 'StartupNotify=true' key be meant for these issues? Like, last time I tried, Openbox presented this problem too with the same applications.
Comment 5 Nils Philippsen 2012-12-13 05:02:18 EST
(In reply to comment #4)
> No pressure at all to answer this as it's just a personal question.
> Wouldn't the 'StartupNotify=true' key be meant for these issues? Like, last
> time I tried, Openbox presented this problem too with the same applications.

I'm just checking the documentation about StartupNotify e.a. -- it's surely not meant as a way to work around such issues and before I change it, I want to be sure that the change I do is standard-conformant.
Comment 6 Adam Williamson 2012-12-19 16:03:58 EST
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . Accepted as NTH - this is an app present on the default menus and failure to launch would block a release-blocking desktop, so clearly NTH for a non-blocking desktop.
Comment 7 Nils Philippsen 2012-12-21 05:23:59 EST
I've tested adding StartupNotify to the desktop file, but it didn't work as expected with the version in F-18 -- the spinner kept spinning until running into a timeout. When wrapping s-c-date with the legacy consolehelper instead of pkexec, it works.
Comment 8 Raphael Groner 2013-01-02 11:29:24 EST
(In reply to comment #7)
> I've tested adding StartupNotify to the desktop file, but it didn't work as
> expected with the version in F-18 -- the spinner kept spinning until running
> into a timeout. When wrapping s-c-date with the legacy consolehelper instead
> of pkexec, it works.

I did a quick and dirty analysis of the upstream source.
https://bugzilla.xfce.org/show_bug.cgi?id=9626#c2
Comment 9 Nils Philippsen 2013-01-02 12:09:55 EST
(In reply to comment #8)
> (In reply to comment #7)
> > I've tested adding StartupNotify to the desktop file, but it didn't work as
> > expected with the version in F-18 -- the spinner kept spinning until running
> > into a timeout. When wrapping s-c-date with the legacy consolehelper instead
> > of pkexec, it works.
> 
> I did a quick and dirty analysis of the upstream source.
> https://bugzilla.xfce.org/show_bug.cgi?id=9626#c2

I didn't express myself clearly, sorry. I didn't mean that it wouldn't be a workaround for the original issue in XFCE, but that -- when used in GNOME shell -- the startup notification mechanism doesn't seem to work: when I start the pkexec-wrapped s-c-date from gnome-shell, the mouse pointer changes to "busy", but didn't change back when s-c-date mapped its window, instead only when running into a timeout.
Comment 10 Raphael Groner 2013-01-02 13:10:10 EST
(In reply to comment #9)
> I didn't express myself clearly, sorry. I didn't mean that it wouldn't be a
> workaround for the original issue in XFCE, but that -- when used in GNOME
> shell -- the startup notification mechanism doesn't seem to work (...)

I don't understand the connection to GNOME. Maybe open a new bug for GNOME, respectively. Currently, this bug is assigned to xfce4-panel that is part of Xfce how it is in the bug title set correctly.

Please try to start s-c-d.desktop with 
StartupNotify=false
Exec=exo-open --launch TerminalEmulator ...

Any success with those two lines? Well, we need a main process that keeps the top parent PID staying alive, otherwise the spawn watcher will horribly fail.
Comment 11 Nils Philippsen 2013-01-08 10:26:11 EST
(In reply to comment #10)
> I don't understand the connection to GNOME. Maybe open a new bug for GNOME,
> respectively. Currently, this bug is assigned to xfce4-panel that is part of
> Xfce how it is in the bug title set correctly.

Sorry for the confusion: I just described why I can't simply add StartupNotify=true as a workaround into s-c-date's desktop file (because it would misbehave when started from GNOME).
Comment 12 Christoph Wickert 2013-01-08 10:40:31 EST
I feel reminded of bug 744535: Something doesn't work in GNOME because GNOME DEs adhere to standards and that's why everybody else needs to suffer. :(

Did you file a bug against GNOME shell?
Comment 13 Nils Philippsen 2013-01-21 12:45:52 EST
*** Bug 901577 has been marked as a duplicate of this bug. ***
Comment 14 Vincent 2013-01-30 02:30:32 EST
hello

running F18 64bits Xfce final and same problem with :
-system-config-users
-system-config-date

no way to launch them with the menu.
But it works well with a terminal.
Comment 15 Doug Enright 2013-02-15 21:04:13 EST
(In reply to comment #14)
> hello
> 
> running F18 64bits Xfce final and same problem with :
> -system-config-users
> -system-config-date
> 
> no way to launch them with the menu.
> But it works well with a terminal.

I've had the same problem with F18, 64-bit running Xfce.

Adding "StartupNotify=true" to the appropriated ,desktop file (e.g. /usr/share/applications/system-config-users.desktop) appeared to fix the problem, i.e. system-config-users & system-config-date are able to be successfully launched from the "Applications Menu".  

Doug
Comment 16 Mukundan Ragavan 2013-02-15 21:24:49 EST
I can confirm that the workaround from Doug (#15) works well.

After adding startupnotify=true, launching from menu works fine.
Comment 17 Pay87 2013-05-11 15:54:55 EDT
Same problem here on F18 x64. system-config-users and system-config-date does not open from menu, but fine from terminal.
Comment 18 Wolfgang Ulbrich 2013-05-15 10:14:53 EDT
@ Christoph and Kevin
This issue was already fixed in GNOME. See
https://bugzilla.gnome.org/show_bug.cgi?id=675789
I did the same for MATE. See
https://github.com/mate-desktop/mate-panel/commit/2905402c0b856eaf86e497c41bbe0d630647c6f6
Hope this will help you.
Comment 19 Raphael Groner 2013-06-01 09:35:45 EDT
Duplication:
https://bugzilla.redhat.com/show_bug.cgi?id=893005
Comment 20 Martin Gregorie 2013-06-11 21:56:04 EDT
This is still a problem with XFCE4 on 32bit/PAE (i686) Fedora 18.
Comment 21 Doug Enright 2013-07-20 15:50:29 EDT
(In reply to Doug Enright from comment #15)
> (In reply to comment #14)
> > hello
> > 
> > running F18 64bits Xfce final and same problem with :
> > -system-config-users
> > -system-config-date
> > 
> > no way to launch them with the menu.
> > But it works well with a terminal.
> 
> I've had the same problem with F18, 64-bit running Xfce.
> 
> Adding "StartupNotify=true" to the appropriated ,desktop file (e.g.
> /usr/share/applications/system-config-users.desktop) appeared to fix the
> problem, i.e. system-config-users & system-config-date are able to be
> successfully launched from the "Applications Menu".  
> 
> Doug

This problem is still present in F19 64-bit.  Adding "StartupNotify=true" fixes the problem.

Are the XFCE developers monitoring this bug?

Doug
Comment 22 Raphael Groner 2013-07-21 02:11:48 EDT
(In reply to Doug Enright from comment #21)
<snip />
> Are the XFCE developers monitoring this bug?
> 
> Doug

Please read my (long) comment [*] in the upstream bug. Maybe you can fix it with a nice patch? :)

<snip />
I bet hardly that is more a GTK bug than a bug for Xfce. Almost cause it's also reported to upstream GNOME as well. GNOME uses a work around in a javascript file.

see
http://bugzilla-attachments.gnome.org/attachment.cgi?id=213776
<snip />

[*] https://bugzilla.xfce.org/show_bug.cgi?id=9626#c2
Comment 23 Kevin Fenzi 2013-08-07 11:19:31 EDT
*** Bug 994513 has been marked as a duplicate of this bug. ***
Comment 24 Alexei Podtelezhnikov 2013-08-09 09:52:23 EDT
That is one really obscure name for the upstream bug [*]! The name should sound alarm on the problem like ours "Fails to open from the Xfce menu" instead of suggesting a fix. I am not surprised that no one pays attention upstream with such a bad name! The importance should also be raised. I suggest refiling the upstream bug report.

[*] https://bugzilla.xfce.org/show_bug.cgi?id=9626
Comment 25 Raphael Groner 2013-08-09 16:14:27 EDT
(In reply to Alexei Podtelezhnikov from comment #24)
> That is one really obscure name for the upstream bug [*]! The name should
> sound alarm on the problem like ours "Fails to open from the Xfce menu"
> instead of suggesting a fix. I am not surprised that no one pays attention
> upstream with such a bad name! The importance should also be raised. I
> suggest refiling the upstream bug report.
> 
> [*] https://bugzilla.xfce.org/show_bug.cgi?id=9626

Why do you post this comment into rhbz and not file it upstream? I bet upstream cares about each bug.

IMHO Fedora or at least Xfce upstream can not do much about our issue. It's more like a deficiency in Gtk, I tried to explain in my comment #22. Please go whining about that instead at the Gnome/Gtk developers, thank you :-)

I don't get the point, really. What's so difficult about changing one setting in the desktop file?
Comment 26 Paul 2013-08-12 16:13:30 EDT
This also exists on 32bit Xfce under Fedora 19 (Comment #21 notes it is present in F19 64-bit).

Workaround for user and date work. I note that keyboard does not work and there isn't a system-config-keyboard installed. I see evidence that there may be a different bug for that, so just note here for completeness.

Paul
Comment 27 David Sandberg 2013-10-13 18:04:44 EDT
>"Many applications that use polkit (pkexec) fail to open from the Xfce menu (and from xfce4-appfinder too) due to this." 

Same here and as a starter from the desktop. F18, xfce4, but the workaround does not work for me.

Any news?

David
Comment 28 Kevin Fenzi 2013-10-19 18:01:18 EDT
As for workarounds, can you try: 

1. yum install polkit-gnome
2. go to sessions and startup pref, choose 'application autostart' and check the 'PolicyKit Authentication agent' item to start on login. 
3. restart and see if things work?
Comment 29 Raphael Groner 2013-10-20 05:16:27 EDT
(In reply to Kevin Fenzi from comment #28)
I have polkit-gnome installed, system-config-keyboard works from the menu. But without a workaround in desktop files, so far no success with the others both, system-config-users and system-config-date; although, those both commands work when I run it from a terminal and I get the login prompt.
Comment 30 David Sandberg 2013-10-20 06:16:46 EDT
Thanks Kevin,
but that doesn't help realy. If I try system-config-network it did not start. If I do gparted from Desktop or start-menu that didn't work too, only the password asking comes. Only for example.
Comment 32 Raphael Groner 2013-11-06 16:34:55 EST
(In reply to Kevin Fenzi from comment #31)

> F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6088584

System-Config-Date works fine here, thanks.
Comment 33 Fedora Update System 2013-11-06 18:53:55 EST
libxfce4ui-4.10.0-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libxfce4ui-4.10.0-9.fc20
Comment 34 Fedora Update System 2013-11-06 18:54:59 EST
libxfce4ui-4.10.0-9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libxfce4ui-4.10.0-9.fc19
Comment 35 Fedora Update System 2013-11-06 18:55:51 EST
libxfce4ui-4.10.0-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libxfce4ui-4.10.0-9.fc18
Comment 36 Fedora Update System 2013-11-07 14:09:36 EST
Package libxfce4ui-4.10.0-9.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libxfce4ui-4.10.0-9.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20872/libxfce4ui-4.10.0-9.fc20
then log in and leave karma (feedback).
Comment 37 Mukundan Ragavan 2013-11-08 12:03:27 EST
The latest update 4.10.0-9 fixes this issue for me. Nice!
Comment 38 David Sandberg 2013-11-08 14:24:39 EST
The update-testing patch for F18 fixes system-config-user and -date, but not the start of gparted neither LVM.
Comment 39 Raphael Groner 2013-11-08 15:29:01 EST
(In reply to David Sandberg from comment #38)
> The update-testing patch for F18 fixes system-config-user and -date, but not
> the start of gparted neither LVM.

That's another use case and has nothing to do with Xfce. Maybe consider to open another bug about gparted and LVM, both are not related to libxfce4ui.

$ grep Exec gparted.desktop 
Exec=/usr/bin/gparted %f
$ file /usr/bin/gparted 
/usr/bin/gparted: symbolic link to `consolehelper'
Comment 40 Raphael Groner 2013-11-08 15:32:11 EST
Besides that, I can not confirm an issue with gparted. I get a password prompt when I click on the menu item.
Comment 41 David Sandberg 2013-11-08 18:57:20 EST
Sorry, than I cannot help. Its only from the xfce-menu or from the dektop-symbol. On the console it works. If I remember correct in the last version LVM was working. Now it does not, but from the terminal it does.

Yes there ist the password dialog, but nothing hapend if click ok.
Comment 42 David Sandberg 2013-11-08 19:07:03 EST
In F17 it was working perfektly.
Comment 43 David Sandberg 2013-11-10 06:59:29 EST
Same with /administration/bootloader - nothing happends.
Comment 44 lnie 2013-11-18 23:26:22 EST
Tested  with libxfce4ui-4.10.0-9.fc20,system-config-user and -date works fine.
But gparted doesn't work,I can do nothing with is,remove,create,resize,etc
Comment 45 David Sandberg 2013-11-19 04:18:12 EST
As another guy in another Bug wrote

>"Many applications that use polkit (pkexec) fail to open from the Xfce menu (and from xfce4-appfinder too) due to this."

Maybe it is another bug, but it doesn't work again.
Comment 46 Fedora Update System 2013-11-23 14:31:47 EST
libxfce4ui-4.10.0-9.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 47 Fedora Update System 2013-11-23 14:39:59 EST
libxfce4ui-4.10.0-9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 48 Fedora Update System 2013-11-23 23:05:59 EST
libxfce4ui-4.10.0-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 49 Doug Enright 2013-11-24 00:07:53 EST
system-config-users & system-config-date are now working as expected with the updated libxfce4ui (4.10.0-9) pushed to the Fedora 19 repository.

Thanks.

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