launch helper exited with unknown return code 127

Florin Gherendi florin_gf at yahoo.fr
Mon Jun 6 13:08:59 UTC 2016


On 06/06/2016 02:08 PM, Simon McVittie wrote:
> On 02/06/16 08:12, Florin Gherendi wrote:
>> This is my first message to this list.
>> I've compiled and installed dbus 1.10.6
> 
> That is not a current version. You probably want the current stable
> version, which is currently 1.10.8. (However, 1.10.8 does not contain
> any fixes directly related to what you're reporting.)
> 
>> on an ARM DD-WRT WiFi router
> 
> dbus is typically compiled by operating system integrators, not by end
> users. If you are compiling it yourself, you are effectively making your
> own operating system variant.
> 
> You might have better success by using a software distribution that
> already offers dbus as an optional component, such as OpenWRT.
> 
>> It will always give me "launch helper exited with unknown return code
>> 127" when try to launch manually
> 
> 127 is traditionally the exit code used by shells when the process to be
> executed does not exist.
> 
> I suspect that this means that either the setuid-root system activation
> helper (dbus-daemon-launch-helper), or the service you are trying to
> activate (for example colord), does not exist at its expected location.
> 
>> I must say that I modified installation root dir to /opt, since the root
>> filesystem is read only; but the config files are all changed
>> accordingly, and I've even tried to change the default search dirs in
>> the sources, but with no success.
> 
> The correct way to configure dbus to install in /opt (or any other
> directory of your choice) is to run ./configure with --prefix=/opt (or
> whatever directory you want). You can't usually just move compiled Unix
> system software around and expect it to work; you should configure with
> the same prefix you are going to use.
> 
> From what you've written about colord, it seems you might be trying to
> use --prefix=/opt/usr, which is unusual but valid.
> 
>> The service
>> org.freedesktop.ColorManager (as I was talking about colord) is system
>> wide known, cause dbus does not complain about the name (it *does*
>> complain if I use an unknown service name), but when I try to list all
>> services with "dbus-send --system --dest=org.freedesktop.DBus
>> --type=method_call --print-reply /org/freedesktop/DBus
>> org.freedesktop.DBus.ListNames" it does not get listed.
> 
> If colord isn't running, then this is the expected result. Call
> ListActivatableNames instead of ListNames to see whether dbus-daemon
> thinks colord is available for activation.
> 

Hi, thanks for the answer.

As I've already posted today, I've solved the problem.
You are right, I've built a LinuxFromScratch system as optware on top of
DD-WRT, so it really is my own system. I might make it public if anybody
wants to; I even have X libraries, Mesa and GTK+ running on it, which
surely OpenWRT does not have. I prefered DD-WRT to OpenWRT because of
some missing features in OpenWRT, long list, useless to talk about it
here. Optwares are compatible, anyway.
I will consider updating to dbus 1.10.8, but for now I've managed to
make 1.10.6 work like a charm.
Yes, I was using configure --prefix=/opt/usr, and I did use "make
install", didn't even try to move any file except documentation, but it
was not enough. Some files location is "hardwired" inside the dbus
sources and will not adapt to --prefix=/opt/usr unless I make symlink to
where they are expected to be; which I can't, especially for
/usr/share/colord /usr is not writable). Changing the locations stated
in the sources was the only way, so I did.

Permissions were ok, just that dbus-daemon-launch-helper could not find
libdbus-1.so.3; I noticed that trying to launch it in command line as
non-root user, which I hadn't done before (as root it did launch).
Simply executing ldconfig solved the problem.

I've only got some tweakings left for colord, cause it works now, it can
create devices and profiles, but it doesn't load system wide icc
profiles (and yes, they are where "make install" puts them; another
issue of the non-standard installation prefix). But that is not for this
list, I guess :)

Best wishes
Florin




More information about the dbus mailing list