Screen Display 'Apply' fails

[Max Waterman]

Since upgrading to 16.04, when I click on the 'Apply' button of the 'Screen Display' utility (without setting anything), I get an error dialog:

"Failed to apply configuration: %s
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.gnome.SettingsDaemon.XRANDR_2' on object at path /org/gnome/SettingsDaemon/XRANDR"

What I expect to be able to configure multiple monitors - though it fails even when I have none connected.

It is a Lenovo X250 with a docking station (though it doesn't make any difference if the docking station is used or not).

WORKAROUND: sudo ln -s /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xorg 1:7.7+13ubuntu3
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
.tmp.unity_support_test.0:

ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Tue May 3 13:20:37 2016
DistUpgraded: 2016-04-22 10:05:12,580 DEBUG icon theme changed, re-reading
DistroCodename: xenial
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Broadwell-U Integrated Graphics [17aa:2226]
InstallationDate: Installed on 2015-05-20 (348 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: LENOVO 20CM001QUK
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-21-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to xenial on 2016-04-22 (11 days ago)
dmi.bios.date: 04/06/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: N10ET33W (1.12 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20CM001QUK
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN10ET33W(1.12):bd04/06/2015:svnLENOVO:pn20CM001QUK:pvrThinkPadX250:rvnLENOVO:rn20CM001QUK:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20CM001QUK
dmi.product.version: ThinkPad X250
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.12.2+16.04.20160415-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.67-1
version.libgl1-mesa-dri: libgl1-mesa-dri 11.2.0-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 11.2.0-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.18.3-1ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Tue May 3 12:33:42 2016
xserver.configfile: default
xserver.errors:
 intel(0): page flipping failed, on CRTC:25 (pipe=1), disabling synchronous page flips
 intel(0): failed to set mode: No such file or directory [2]
 intel(0): Failed to restore display configuration
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 1079
 vendor LGD
xserver.version: 2:1.18.3-1ubuntu2

[Max Waterman (b-ubuntuone)]

I should add that, if I boot my laptop with it in the doc and monitors connected, then they are configured in 'mirrored' mode, and work as expected. Of course, that's not what I want and any attempt to use the 'Screen Display' tool to change the configuration fails with the error mentioned above.

[Max Waterman (b-ubuntuone)]

This is the xdpyinfo output with the monitors running in 'mirror' mode after booting the laptop docked with monitors attached.
(I attach this because I imagine the one obtained by the bug tool was probably not the same)

[Max Waterman (b-ubuntuone)]

I notice that one of my monitors is 'lost' (the BenQ one) if the laptop is allowed to go to sleep and then awoken. The 'Screen Display' tool is still 'non-functional'.

[Max Waterman (b-ubuntuone)]

Prompted by all the upowerd errors in syslog, I tried to run it manually...

[~]$ gnome-settings-daemon --replace

(gnome-settings-daemon:8495): libupower-glib-WARNING **: Couldn't connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.UPower': timed out
Segmentation fault (core dumped)

25000 May 4 11:00:04 mwaterm1-x250 upowerd[8572]: /usr/lib/upower/upowerd: error while loading shared libraries: libusbmuxd.so.2: cannot open shared object file: No such file or directory
25001 May 4 11:00:04 mwaterm1-x250 systemd[1]: upower.service: Main process exited, code=exited, status=127/n/a
25002 May 4 11:00:04 mwaterm1-x250 systemd[1]: Failed to start Daemon for power management.
25003 May 4 11:00:04 mwaterm1-x250 systemd[1]: upower.service: Unit entered failed state.
25004 May 4 11:00:04 mwaterm1-x250 systemd[1]: upower.service: Failed with result 'exit-code'.
25005 May 4 11:00:04 mwaterm1-x250 systemd[1]: upower.service: Service hold-off time over, scheduling restart.
25006 May 4 11:00:04 mwaterm1-x250 systemd[1]: Stopped Daemon for power management.
25007 May 4 11:00:04 mwaterm1-x250 systemd[1]: Starting Daemon for power management...
25008 May 4 11:00:04 mwaterm1-x250 upowerd[8574]: /usr/lib/upower/upowerd: error while loading shared libraries: libusbmuxd.so.2: cannot open shared object file: No such file or directory

Since that file isn't found, I figured I'd try to link it just like the libusbmuxd.so.4 (which is installed) to libusbmuxd.so.4.0.0

$ sudo ln -s /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2

and that fixed this error so I can now use the 'Screen Display' tool again - ie the 'Apply' button actually works now.

It seems to me like a few binaries are still linked to libusbmuxd.so.2 instead of .4, and they need rebuilding.

However, the 'Screen Display' tool doesn't register all three monitors I have connected...I presume that is a different problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[penalvch (penalvch)]

Max Waterman, thank you for reporting this and helping make Ubuntu better.

To clarify, did this issue not occur in a release prior to 16.04?

[Max Waterman (b-ubuntuone)]

Correct, the problem started when I *upgraded* from 15.10 to 16.04.

[penalvch (penalvch)]

Max Waterman, for now, let this be recast to the upower package, given this issue has been root caused to it pointing to the wrong file version.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

could you provide the output of those commands?

- dpkg -l | grep upower
- ls -l /usr/lib/upower/upowerd
- ldd -r /usr/lib/upower/upowerd

[Max Waterman (b-ubuntuone)]

[~]$ dpkg -l | grep upower
ii libupower-glib3:amd64 0.99.4-2 amd64 abstraction for power management - shared library
ii upower 0.99.4-2 amd64 abstraction for power management
[~]$ ls -l /usr/lib/upower/upowerd
-rwxr-xr-x 1 root root 227400 Feb 23 09:07 /usr/lib/upower/upowerd
[~]$ ldd -r !$
ldd -r /usr/lib/upower/upowerd
 linux-vdso.so.1 => (0x00007ffcbcffd000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3d9a214000)
 libupower-glib.so.3 => /usr/lib/x86_64-linux-gnu/libupower-glib.so.3 (0x00007f3d99fed000)
 libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f3d99c64000)
 libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f3d99a4c000)
 libgudev-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0 (0x00007f3d99842000)
 libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f3d995ee000)
 libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f3d992dd000)
 libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6 (0x00007f3d990ba000)
 libplist.so.3 => /usr/lib/x86_64-linux-gnu/libplist.so.3 (0x00007f3d98eae000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3d98ae5000)
 /lib64/ld-linux-x86-64.so.2 (0x00005602f9826000)
 libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f3d988e1000)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3d986c6000)
 libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f3d984a4000)
 libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3d98289000)
 libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f3d98268000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3d9804b000)
 libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3d97e43000)
 libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3d97bd2000)
 libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f3d97969000)
 libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f3d9750e000)
 libusbmuxd.so.2 => /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2 (0x00007f3d97305000)
 libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f3d96f4b000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3d96d47000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3d96b3e000)
 libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f3d967aa000)
 liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3d96587000)
 libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f3d94ad0000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3d9474e000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3d94537000)
[~]$

[Sebastien Bacher (seb128)]

Your issue seems to be due to a local installation

libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6 (0x00007f3d990ba000)

Does it work if you delete that local library (which is taking over the system one)? (you should also remove the workaround to make sure it works without it)

[Sebastien Bacher (seb128)]

could you test if the theory of the previous comment is true?

[Max Waterman (b-ubuntuone)]

For the record :

[~]$ ls -l /usr/local/lib/libimobiledevice.so.6*
lrwxrwxrwx 1 root root 25 Apr 12 15:32 /usr/local/lib/libimobiledevice.so.6 -> libimobiledevice.so.6.0.0
-rwxr-xr-x 1 root root 143216 Apr 12 15:32 /usr/local/lib/libimobiledevice.so.6.0.0

So, those were made 'quite some time ago'.

[~]$ mkdir Backup
[~]$ sudo mv /usr/local/lib/libimobiledevice.* Backup
[sudo] password for davidmaxwaterman:
[~]$ ls -l /usr/local/lib/libimobiledevice.so.6*
ls: cannot access '/usr/local/lib/libimobiledevice.so.6*': No such file or directory
[~]$ ldd -r /usr/lib/upower/upowerd | grep imobile
 libimobiledevice.so.6 => /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6 (0x00007f45cde6e000)

I wonder if it is something to do with one of the mobile development SDKs I have installed - Android or Tizen?

I'm not completely sure what you mean by 'Does it work' (i've had a few problems with this upgrade so things are getting a bit blurry). However :

[~]$ gnome-settings-daemon --replace
^C
[~]$

That seems to run, if that is what you mean.

However, that works when I move the libraries back too :

[Backup]$ sudo mv * /usr/local/lib
[Backup]$ ls -l /usr/local/lib/libimobiledevice*
-rw-r--r-- 1 root root 2330698 Apr 12 15:32 /usr/local/lib/libimobiledevice.a
-rwxr-xr-x 1 root root 1041 Apr 12 15:32 /usr/local/lib/libimobiledevice.la
lrwxrwxrwx 1 root root 25 Apr 12 15:32 /usr/local/lib/libimobiledevice.so -> libimobiledevice.so.6.0.0
lrwxrwxrwx 1 root root 25 Apr 12 15:32 /usr/local/lib/libimobiledevice.so.6 -> libimobiledevice.so.6.0.0
-rwxr-xr-x 1 root root 143216 Apr 12 15:32 /usr/local/lib/libimobiledevice.so.6.0.0
[Backup]$ gnome-settings-daemon --replace
^C
[Backup]$

But, as I mentioned, I still have the workaround implemented - ie before filing this bug, I did :

$ sudo ln -s /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2

and that is still effective :

[Backup]$ ls -l /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2
lrwxrwxrwx 1 root root 45 May 4 11:03 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2 -> /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0

And the ldd output shows it is linked to the .so.2 version :

 libusbmuxd.so.2 => /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2 (0x00007f3d97305000)

IMO, the /usr/lib/upower/upowerd binary should be relinked against the .so.4 version (or plain .so), then it would use a version that is installed by default :

[Backup]$ ls -l /usr/lib/x86_64-linux-gnu/libusbmuxd.so*
lrwxrwxrwx 1 root root 19 Jan 4 23:13 /usr/lib/x86_64-linux-gnu/libusbmuxd.so -> libusbmuxd.so.4.0.0
lrwxrwxrwx 1 root root 45 May 4 11:03 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2 -> /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0
lrwxrwxrwx 1 root root 19 Jan 4 23:13 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4 -> libusbmuxd.so.4.0.0
-rw-r--r-- 1 root root 31224 Jan 4 23:13 /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.0.0

You can see the dates there, indicating the manually symlinked version.

[Max Waterman (b-ubuntuone)]

Ah, I think I just 'got' what you were suggesting. If I move the /usr/local/lib/libimobiledevice* away, and then look at the ldd output from upowerd, I see that it indeed shows it linked to libusbmuxd.so.4, rather than .2.

[~]$ ldd -r /usr/lib/upower/upowerd | grep usbmuxd
 libusbmuxd.so.4 => /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4 (0x00007f35bc721000)

So, yes, that /usr/local/lib/ library was causing a dependency on the old version of the libusbmuxd library.

Following that line of thinking, I also removed the workaround and, yes:

[~] gnome-settings-daemon --replace

still runs.

If I then reboot, all works as planned (command line and the Apply button itself). I think you're right.
upowerd was being linked to /usr/local/lib/libimobiledevice.so.6 instead of /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6, and the former was linked to /usr/lib/x86_64-linux-gnu/libusbmuxd.so.2, instead of /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4.

So, why is upowerd getting linked to /usr/local/lib/libimobiledevice.so.6 in the first place?

[Sebastien Bacher (seb128)]

> So, why is upowerd getting linked to /usr/local/lib/libimobiledevice.so.6 in the first place?

well, upower is linked to libimobiledevice.so.6, then the glibc loader is looking for available versions in the standard path and "/usr/local" has the priority, it's there to let admins setup local overrides and "taking over the distro version" if needed. That's handy if you for some reason need to maintain a modified version on your system, but it can lead situations where you shoot yourself in the foot like here...

closing the bug as invalid, it's not a distro issue

[rdz (reduzierer)]

I'm experiencing the same problem, but I don't have /usr/local/lib/libimobiledevice.so.6 installed. So it seems that there are more than one condition that triggers the exact same behaviour. I'm using i386 16.04 (not amd64), though.

I still don't have a clue what is causing this. BTW. I experience the same issue on two different machines.

[Bernhard Zürn (bernhard-zuern)]

I also do not have /usr/local/lib/libimobiledevice.so.6 on 16.04 amd64

[rdz (reduzierer)]

I said in my previous post that I do _not_ have usr/local/lib/libimobiledevice.so.6 installed. Also, I'm running Ubuntu 16.04 _i386_, not amd64. Thus, I assume there is another trigger that exhibits the bug than the one described in the first post of this thread.

[Max Waterman (b-ubuntuone)]

I would do :

[~]$ ls -l /usr/lib/upower/upowerd
-rwxr-xr-x 1 root root 227400 Feb 23 09:07 /usr/lib/upower/upowerd
[~]$ ldd -r !$
ldd -r /usr/lib/upower/upowerd

and look for anything unusual in the output...iirc mine contained a lib from /use/local, which is non standard, but it could be anywhere.

[rdz (reduzierer)]

Thanks for the suggestion. I cannot spot anything 'unusual' in the output. Or is there?

ldd -r /usr/lib/upower/upowerd
 linux-gate.so.1 => (0xb77ed000)
 libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7725000)
 libupower-glib.so.3 => /usr/lib/i386-linux-gnu/libupower-glib.so.3 (0xb76fa000)
 libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb7530000)
 libusb-1.0.so.0 => /lib/i386-linux-gnu/libusb-1.0.so.0 (0xb7515000)
 libgudev-1.0.so.0 => /usr/lib/i386-linux-gnu/libgudev-1.0.so.0 (0xb750a000)
 libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb74ab000)
 libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb7382000)
 libimobiledevice.so.6 => /usr/lib/i386-linux-gnu/libimobiledevice.so.6 (0xb7359000)
 libplist.so.3 => /usr/lib/i386-linux-gnu/libplist.so.3 (0xb734c000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7196000)
 /lib/ld-linux.so.2 (0x8000c000)
 libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb7191000)
 libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7176000)
 libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb714f000)
 libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb7136000)
 libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb7115000)
 libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb70f8000)
 libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb70ef000)
 libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb7079000)
 libgnutls.so.30 => /usr/lib/i386-linux-gnu/libgnutls.so.30 (0xb6f21000)
 libtasn1.so.6 => /usr/lib/i386-linux-gnu/libtasn1.so.6 (0xb6f0c000)
 libgcrypt.so.20 => /lib/i386-linux-gnu/libgcrypt.so.20 (0xb6e5d000)
 libusbmuxd.so.4 => /usr/lib/i386-linux-gnu/libusbmuxd.so.4 (0xb6e53000)
 libxml2.so.2 => /usr/lib/i386-linux-gnu/libxml2.so.2 (0xb6c75000)
 libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6c70000)
 librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6c67000)
 libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6c4a000)
 libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xb6be8000)
 libidn.so.11 => /usr/lib/i386-linux-gnu/libidn.so.11 (0xb6bb3000)
 libnettle.so.6 => /usr/lib/i386-linux-gnu/libnettle.so.6 (0xb6b77000)
 libhogweed.so.4 => /usr/lib/i386-linux-gnu/libhogweed.so.4 (0xb6b42000)
 libgmp.so.10 => /usr/lib/i386-linux-gnu/libgmp.so.10 (0xb6ab6000)
 libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb6aa0000)
 libicuuc.so.55 => /usr/lib/i386-linux-gnu/libicuuc.so.55 (0xb6909000)
 liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb68e3000)
 libicudata.so.55 => /usr/lib/i386-linux-gnu/libicudata.so.55 (0xb502b000)
 libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb4eb4000)

[Max Waterman (b-ubuntuone)]

Is it upowerd that is crashing or something else? I think I noticed messages in /var/log/syslog. That might identify some other binary that is failing to load - perhaps grep the logs for 'error while loading shared libraries'?

Alternatively, you could try ldd on all the binaries in /usr/bin and /bin and see if any of the give anything in /usr/local. A bit heavy handed, but something like this? :

$ ldd /usr/bin/* | awk '/:$/ { problemfile=$0 } /local/ { print problemfile; print $0}'

and on /bin/* too?

...or, just move /usr/local to /usr/local.old and see if that fixes it. However, I'm not sure if an errant library *has* to be in /usr/local though - it might be finding one somewhere else (it used to be that you could add paths to the LD_LIBRARY_PATH environment variable to get ldd to look in other places - do you have that set by any chance? [printenv | grep LD_LIBRARY_PATH]).

I'm just guessing...sorry.

[rdz (reduzierer)]

Thanks, Max, for all the suggestions. Don't be sorry for giving clues...

* While I trigger the error, nothing is written to /var/log/syslog. Also there is no indication of 'error while loading shared libraries'.

* I looked for any binary in /usr/bin/ and /bin that might is linked to something in /usr/local. No result. I even tried renaming /usr/local to /usr/local.old and tried to set displays again, but the error still appears.

I don't know if this is important information, but I have the same behaviour on two different Ubuntu 16.04 LTS installations. Both are i386 (does that make a difference?) and both are not fresh installs, but have been upgraded from LTS to LTS since at least 10.04.

[Max Waterman (b-ubuntuone)]

Hrm. It's almost like it's not really the same issue (particularly not the same *cause*).

Can you check that upowerd is actually running? :

$ ps faux | grep upowerd
maxw 4799 0.0 0.0 21296 932 pts/1 S+ 10:38 0:00 \_ grep --color=auto upowerd
root 2515 0.0 0.1 354340 3928 ? Ssl 08:52 0:01 /usr/lib/upower/upowerd

If it is running ok then I'd assume it's not the same cause and perhaps we should go back to square one. What exactly is happening and what is common with this bug?

You mention 'the error' so I presume it is the 'failed to apply configuration' error mentioned in the first comment - is it exactly the same, ie it's concerning the settings daemon? If so, then perhaps see if that is actually running :

$ ps faux | grep settings
maxw 2888 0.0 0.8 862212 16576 ? Ssl 08:52 0:01 \_ /usr/lib/unity-settings-daemon/unity-settings-daemon
maxw 3062 0.0 0.4 576748 9960 ? Sl 08:52 0:00 | \_ /usr/lib/unity-settings-daemon/unity-fallback-mount-helper
maxw 4828 0.0 0.0 21296 972 pts/1 S+ 10:41 0:00 \_ grep --color=auto settings

In the above, I presume it is process 2888. If that is not running on your system, perhaps you should try running it and see what it complains about. Note it is in /usr/lib, so the ldd tests we did on /usr/bin and /bin wouldn't have caught that - perhaps try running ldd on it specifically (that's if running it directly doesn't already tell you what it fails to link to).

Interestingly, I notice that my trouble was with a binary called 'gnome-settings-daemon', but on my current system (I no longer have access to the one I was using when filing this issue) I don't have that binary at all....when I attempt to run it, bash suggests I install it. I would ignore gnome-settings-daemon and try to see what unity-settings-daemon is having a problem with, if anything - same technique though.

[rdz (reduzierer)]

Dear Max

You nailed it! Your last suggestion regarding gnome-settings-daemon and unity-settings-daemon was pointing me to the right direction. I indeed was running gnome-settings-daemon and the problem disappears when running unity-settings-daemon instead.

I'm running fluxbox as window manager and thus still had gnome-settings-daemon in the startup file. I'd I run unity once, I'd noticed the problem doesn't exist there...

Thanks a lot for your help.

[Max Waterman (b-ubuntuone)]

Wow, I'm so pleased I was able to help. I used to work for Global Product Support at Silicon Graphics, and this reminds me of how much I enjoyed that job :) Now I do web application development, which can be pleasing at times too.