After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335262 - panel doesn't detect failure to start
panel doesn't detect failure to start
Status: RESOLVED DUPLICATE of bug 144961
Product: gnome-panel
Classification: Other
Component: panel
2.12.x
Other All
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-20 18:44 UTC by Mark Gordon
Modified: 2006-03-20 20:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Mark Gordon 2006-03-20 18:44:37 UTC
Please describe the problem:
If you launch something from the panel but it exits with an error, the panel
doesn't tell you this. In fact, it eventually gives you a watch cursor to make
you think it's still loading.  For instance, create a panel launcher for
"/bin/false", and click on it. You'd expect to get some error along the lines of
"the application failed to run" or something (since it returned a non-0 exit
status), but it doesn't.

In one case, aisleriot was exiting with an error, but the panel made it seem
like it was just being really really really slow to launch.

Steps to reproduce:
1. create a panel launcher for "/bin/false"
2. double-click it


Actual results:
Silence

Expected results:
An error indicating that the "app" had immediately closed with non-zero exit value.

Does this happen every time?
Oh, yes.

Other information:
Comment 1 Vincent Untz 2006-03-20 20:14:36 UTC
A bit related to bug 144961.

So, you're example is not really good since running /bin/false actually works. And I don't believe that all programs returning a non-zero value do this because of errors...
Comment 2 Dan Winship 2006-03-20 20:30:42 UTC
In fact, the downstream bug Mark copied this from was basically exactly 144961.
("Make a launcher to /bin/false" was just something I suggested as an easy way
to reproduce it without needing to have an app with broken rpath/ldconfig info.)


*** This bug has been marked as a duplicate of 144961 ***