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.

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).

*** Bug 879591 has been marked as a duplicate of this bug. ***

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.

(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.

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.

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.

(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

(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.

(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.

(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).

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?

*** Bug 901577 has been marked as a duplicate of this bug. ***

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.

(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

I can confirm that the workaround from Doug (#15) works well.

After adding startupnotify=true, launching from menu works fine.

Same problem here on F18 x64. system-config-users and system-config-date does not open from menu, but fine from terminal.

@ 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.

Duplication:
https://bugzilla.redhat.com/show_bug.cgi?id=893005

This is still a problem with XFCE4 on 32bit/PAE (i686) Fedora 18.

(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

(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

*** Bug 994513 has been marked as a duplicate of this bug. ***

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

(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?

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

>"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

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?

(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.

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.

ok, can folks try these scratch builds? 

F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6088631
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6088584
F18: http://koji.fedoraproject.org/koji/taskinfo?taskID=6088596

(In reply to Kevin Fenzi from comment #31)

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

System-Config-Date works fine here, thanks.

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

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

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

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).

The latest update 4.10.0-9 fixes this issue for me. Nice!

The update-testing patch for F18 fixes system-config-user and -date, but not the start of gparted neither LVM.

(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'

Besides that, I can not confirm an issue with gparted. I get a password prompt when I click on the menu item.

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.

In F17 it was working perfektly.

Same with /administration/bootloader - nothing happends.

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

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.

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.

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.

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.

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.