redshift disallowed from using GeoClue

Created on 16 Jul 2018  路  42Comments  路  Source: jonls/redshift

While googling around has showed me this exact same issue multiple times, this is the only instance of this issue where even when modifying the geoclue config file doesn't seem to work properly.

I'm running Arch Linux, and I've been trying to get redshift to work using both the (Arch Wiki article about redshift)[https://wiki.archlinux.org/index.php/Redshift], the redshift FAQ and the numerous issue reports related.

The following snippet has been added at the end of etc/geoclue/geoclue.conf

[redshift]
allowed=true
system=false
users=

I've restarted the system several times after changing the geoclue configuration, and I've also tried to run redshift both with the systemd unit service and manually from the terminal, but both have the same effect.

Trying location provider `geoclue2'...
Using provider `geoclue2'.
Using method `randr'.
Waiting for initial location to become available...
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'redshift' disallowed, no agent for UID 1000.
Access to the current location was denied by GeoClue!
Make sure that location services are enabled and that Redshift is permitted
to use location services. See https://github.com/jonls/redshift#faq for more
information.
Unable to get location from provider.

I've also tried to change the geoclue config to the following one, with no luck.

[redshift]
allowed=true
system=false
users=1000

My desktop environment is i3wm, which doesn't have any sort of location settings that could be disabled. Redshift has been installed from the official arch repositories, so there shouldn't be any issue regarding a wrong installation, but I also installed the git version just in case, with the same results.

The redshift version I'm using is 1.12, and the version of geoclue installed is 2.4.10-1.

Let me know if I can add any more info that could be relevant to the issue at hand.

Most helpful comment

It seems like the issue is that on the part of the code that works with geoclue, on the line 247, this piece of code is returning NULL instead of whatever it has to return.

ret_v = g_dbus_proxy_call_sync(geoclue_client, "Start", NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);

I'll try to check if I can find the root of the issue, knowing that downgrading geoclue fixes the issue.

All 42 comments

I can reproduce this on Arch Linux running cinnamon. I also had an issue with "UnknownMethod" errors. I fixed the issue by downgrading to geoclue2 v2.4.7-1. Perhaps redshift is using some deprecated methods in geoclue2 that were removed with the latest update?

It seems like the issue is that on the part of the code that works with geoclue, on the line 247, this piece of code is returning NULL instead of whatever it has to return.

ret_v = g_dbus_proxy_call_sync(geoclue_client, "Start", NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);

I'll try to check if I can find the root of the issue, knowing that downgrading geoclue fixes the issue.

I am using KDE, after adding Redshift to system tray, it works, before that it wasn't.

Same here, in Arch Linux with KDE. Problems started after updating the geoclue package from 2.4.7-1 to 2.4.10-1 earlier today. Still using the old redshift 1.11-5. Haven't tried the Redshift Control applet for Plasma 5.

I'm using the applet and it doesn't help at all. With a little Google-fu I was able to find that this is a pretty consistent issue and found others who suggested it's a bug in geoclue itself but I can't verify that. I'm going to try rolling back to an earlier version and see what happens.

Edit: I used https://archive.org/download/archlinux_pkg_geoclue2/geoclue2-2.4.4-1-x86_64.pkg.tar.xz and it's working perfectly!

It looks like geoclue crashes, before redshift start, systemctl status geoclue says 'active', and after it says 'inactive (dead)'.

I can confirm this on Arch with i3wm and redshift-gtk in i3 autostart using the exec --no-startup-id redshift-gtk command in my i3 config. The geoclue service crashes when launching redshift. Downgrading to geoclue2-2.4.3-1 resolves the issue for the moment.

I can confirm that on my Fedora 28 box, downgrading geoclue2 from 2.4.10 to 2.4.8 allows the geoclue service to run and allows redshift and the where-am-i demo to access geoclue. Prior to the downgrade, the geoclue service would try to start but promptly die.

There is a patch in git master that hopefully helps here. I was going to roll out a release but i was waiting on the new meson build to be tested a bit before i make the first release with meson build system. But since this patch is important, I'll roll out a release already today.

Here is the PR in question: https://gitlab.freedesktop.org/geoclue/geoclue/merge_requests/6

I run Arch and have been affected by this - looking forward to the new release. In the meantime here's my workaround (if you don't want to/can't downgrade geoclue2; you'll need jq package):

#!/bin/bash
# This script fetches lat and long information from Mozilla's geolocation service. It then passes
# lat and long to redshift-gtk. If geolocation service is not available (e.g. no internet
# connection, service down) it sleeps and retries.

# URL taken from geoclue2. It returns JSON document with LAT and LONG.
URL="https://location.services.mozilla.com/v1/geolocate?key=16674381-f021-49de-8622-3021c5942aff"
# LAT and LONG numbers in the following format: "LAT:LON"
COORDS=""

function get_geolocation() {
  exit_status=1
  retry_times=30
  sleep_time=15

  while [ $exit_status -ne 0 ] && [ $retry_times -gt 0 ]; do
    sleep $sleep_time
    echo "Trying to fetch geolocation coordinates from $URL"
    json_coords=$(curl -s $URL)
    exit_status=$?
    retry_times=$((retry_times - 1))
  done

  echo "Received: $json_coords"
  COORDS=$(jq -c -r '[.location.lat, .location.lng] | @csv' <<< $json_coords | sed 's/,/:/')
}

get_geolocation

if [ -z "$COORDS" ]; then
  echo "Unknown Error: LAT and LONG not set. Is JSON response malformed or has a different schema?"
  exit 1
fi

redshift-gtk -l $COORDS

I use awesome-wm and have replaced redshift-gtk & with this script to auto-start in the background.

Same issue here, running Arch with awesome-wm. Waiting eagerly for the fix!!!

@TerminalWitchcraft Have you updated to geoclue 2.4.10-1.2? It works for me.

EDIT : Also trusting redshift like in the OP and adding geoclue to startup like in the post below.

Hello. In my case I think it has been solved for me by making a symbolic link of the file:
/etc/xdg/autostart/geoclue-demo-agent.desktop,
into the directory:
~/.config/autostart.
Hope it works for other people.
Also, I use Plasma as my Desktop Environment and Arch Linux as my Linux distribution.

@LongLVNH @yochananmarqos than your DE is not XDG-compliant and that's a pretty major bug. Please report it to them because geoclue (and other freedesktop.org software) rely on this compliance.

@zeenix Of course Cinnamon is xdg compliant. I'm using Manjaro.

@yochananmarqos that's great. I think i tagged you by accident. I was talking to @LongLVNH, whose desktop is obviously not compliant if he had to move the desktop file to his home director for autostart to work.

Thank you @zeenix. Indeed that is the case ( Plasma is not XDG compliant ). I know about XDG but did not know that Plasma was not compliant with it. In my case I read in https://github.com/jonls/redshift/issues/318 that the demo agent needed to be executed. Then inspected the contents of the package geoclue2 and found that XDG file.

Also I have reported the bug at KDE ( https://bugs.kde.org/show_bug.cgi?id=310657 ).

Well, you commented on an old, slightly related one. Someone there answered:

As for the latest comment, I can assure you that plasma5 does comply with XDG standards, autostart in particular, in general. Many plasma services, including baloo, powerdevil, polkit-kde-authentication-agent, etc... rely on that successfully.

And indeed, when you check the file list of baloo you see /etc/xdg/autostart/baloo_file.desktop.

@LongLVNH @flying-sheep it might be a timing issue. i-e Plasma could be launching the desktop files from home dir before it launches from /etc.

seems likely! desktop files aren鈥檛 systemd units with dependencies and so on.

why is geoclue started via autostart and not systemd? it doesn鈥檛 seem like a desktop-only service.

So on popular demand, I just rolled out a new release with the fix: http://www.freedesktop.org/software/geoclue/releases/2.4/geoclue-2.4.11.tar.xz

I've just tested it out, and it works like a charm. Thank you @zeenix!

One last thing: I've noticed that every time I start redshift I'm asked to allow location access. Is this intentional?

@Myl0g no problem. Thanks for testing.

The UI you see now is a demo agent and not a full fledged one, that should be provided by your DE (if they care about your privacy). It's not just about saving the user's preference for each app but also allowing them to:

  • Disable/enable geolocation all together at any point.
  • Disable/enable access to each app, that you have given access to in the past.

If you believe in the DE you choose and you agree with me, please do file bugs on your DE about implementing an agent.

@zeenix I switched to XFCE in the middle of all this. I鈥檒l look into my options, see if I can fix it myself, and I鈥檒l file bugs if I can鈥檛. Thank you!

The geoclue package in the official Arch repositories has been flagged out of date. Hope they will update to the latest version soon. Currently still on version 2.4.10-1

If you want it right now, here's my PKGBUILD for it:

# $Id$
# Maintainer: Jan Alexander Steffens (heftig) <[email protected]>
# Contributor: Gy枚rgy Ball贸 <[email protected]>

pkgname=geoclue2
pkgver=2.4.11
pkgrel=1
pkgdesc="Modular geoinformation service built on the D-Bus messaging system"
arch=(x86_64)
url="https://www.freedesktop.org/wiki/Software/GeoClue/"
license=(LGPL)
depends=(libsoup json-glib libmm-glib avahi libnotify)
makedepends=(intltool python2 systemd gobject-introspection gnome-common git)
backup=(etc/geoclue/geoclue.conf)
_commit=69a5d624c636f4e1fd6471db0d55b1100a0c4e65  # tags/2.4.11^0
source=("git+https://anongit.freedesktop.org/git/geoclue#commit=$_commit")
sha256sums=('SKIP')

# Google API keys (see http://www.chromium.org/developers/how-tos/api-keys)
# Note: These are for Arch Linux use ONLY. For your own distribution, please
# get your own set of keys. Feel free to contact [email protected] for
# more information.
_google_api_key=AIzaSyDwr302FpOSkGRpLlUpPThNTDPbXcIn_FM

# Mozilla API keys (see https://location.services.mozilla.com/api)
# Note: These are for Arch Linux use ONLY. For your own distribution, please
# get your own set of keys. Feel free to contact [email protected] for
# more information.
_mozilla_api_key=16674381-f021-49de-8622-3021c5942aff

pkgver() {
  cd geoclue
  git describe --tags | sed 's/-/+/g'
}

prepare() {
  cd geoclue
  sed -e "s/key=geoclue/key=$_mozilla_api_key/" \
      -e "s/key=YOUR_KEY/key=$_google_api_key/" \
      -i data/geoclue.conf.in
  NOCONFIGURE=1 ./autogen.sh
}

build() {
  cd geoclue
  ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
    --libexecdir=/usr/lib --disable-static --enable-gtk-doc
  sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
  make
}

package() {
  cd geoclue
  make DESTDIR="$pkgdir" install
}

The only difference is the pkgver and _commit variables (to reflect the new version).

Downgrading the package works, thanks. Mate Desktop here, Arch x64.

Update to 2.4.11 didn't solve the problem. Fedora 28 x64, KDE Plasma 5.13

@flying-sheep Sorry, i had missed your question about launch. Geoclue is launched with systemd, as it should be. It's the demo agent that is being launched through autostart cause agents are per-user instances.

@Latesil :( does this workaround helps? https://github.com/jonls/redshift/issues/636#issuecomment-407612969 It really shouldn't be needed with the new geoclue release but let's see.

I'm still seeing a crash with 2.4.11-1 on Arch Linux, no DE.

geoclue[5020]: g_object_unref: assertion 'object->ref_count > 0' failed
geoclue[5020]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
kernel: geoclue[5020]: segfault at 55a100000001 ip 00007fc28ce4b5c6 sp 00007ffc2c8a7740 error 4 in libc-2.27.so[7fc28cdc8000+1b3000]
systemd[1]: Created slice system-systemd\x2dcoredump.slice.
systemd[1]: Started Process Core Dump (PID 5067/UID 0).
systemd[1]: geoclue.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: geoclue.service: Failed with result 'core-dump'.
systemd-coredump[5068]: Process 5020 (geoclue) of user 0 dumped core.

                        Stack trace of thread 5020:
                        #0  0x00007fc28ce4b5c6 malloc (libc.so.6)
                        #1  0x00007fc28d56aaca g_malloc (libglib-2.0.so.0)
                        #2  0x00007fc28d584aad g_memdup (libglib-2.0.so.0)
                        #3  0x00007fc28d53e1f8 g_bytes_new (libglib-2.0.so.0)
                        #4  0x00007fc28d59b0f5 n/a (libglib-2.0.so.0)
                        #5  0x00007fc28db4aebc n/a (libgio-2.0.so.0)
                        #6  0x00007fc28db4c040 g_dbus_message_new_method_call (libgio-2.0.so.0)
                        #7  0x00007fc28db4364b n/a (libgio-2.0.so.0)
                        #8  0x00007fc28db477d9 g_dbus_connection_signal_unsubscribe (libgio-2.0.so.0)
                        #9  0x00007fc28db5166f n/a (libgio-2.0.so.0)
                        #10 0x00007fc28d844b05 g_object_unref (libgobject-2.0.so.0)
                        #11 0x000055a1443a7e3d n/a (geoclue)
                        #12 0x00007fc28d844b05 g_object_unref (libgobject-2.0.so.0)
                        #13 0x00007fc28d56145d g_list_foreach (libglib-2.0.so.0)
                        #14 0x00007fc28d56148c g_list_free_full (libglib-2.0.so.0)
                        #15 0x000055a1443a639c n/a (geoclue)
                        #16 0x00007fc28d844b05 g_object_unref (libgobject-2.0.so.0)
                        #17 0x000055a144398596 n/a (geoclue)
                        #18 0x00007fc28d844b05 g_object_unref (libgobject-2.0.so.0)
                        #19 0x000055a14439698b n/a (geoclue)
                        #20 0x00007fc28cdeb06b __libc_start_main (libc.so.6)
                        #21 0x000055a144396a4a n/a (geoclue)

                        Stack trace of thread 5029:
                        #0  0x00007fc28cebb0f9 syscall (libc.so.6)
                        #1  0x00007fc28d5aba1d n/a (libglib-2.0.so.0)
                        #2  0x00007fc28db3ffbd n/a (libgio-2.0.so.0)
                        #3  0x00007fc28db55a18 n/a (libgio-2.0.so.0)
                        #4  0x00007fc28db55bb9 n/a (libgio-2.0.so.0)
                        #5  0x00007fc28d5651d6 g_main_context_dispatch (libglib-2.0.so.0)
                        #6  0x00007fc28d5655b1 n/a (libglib-2.0.so.0)
                        #7  0x00007fc28d5658e2 g_main_loop_run (libglib-2.0.so.0)
                        #8  0x00007fc28db54348 n/a (libgio-2.0.so.0)
                        #9  0x00007fc28d58da2a n/a (libglib-2.0.so.0)
                        #10 0x00007fc28cbb1075 start_thread (libpthread.so.0)
                        #11 0x00007fc28cec053f __clone (libc.so.6)

                        Stack trace of thread 5027:
                        #0  0x00007fc28ceb5ea9 __poll (libc.so.6)
                        #1  0x00007fc28d565523 n/a (libglib-2.0.so.0)
                        #2  0x00007fc28d56563e g_main_context_iteration (libglib-2.0.so.0)
                        #3  0x00007fc28d565692 n/a (libglib-2.0.so.0)
                        #4  0x00007fc28d58da2a n/a (libglib-2.0.so.0)
                        #5  0x00007fc28cbb1075 start_thread (libpthread.so.0)
                        #6  0x00007fc28cec053f __clone (libc.so.6)

                        Stack trace of thread 5028:
                        #0  0x00007fc28cebb0f9 syscall (libc.so.6)
                        #1  0x00007fc28d5ac52d g_cond_wait_until (libglib-2.0.so.0)
                        #2  0x00007fc28d537903 n/a (libglib-2.0.so.0)
                        #3  0x00007fc28d537eee g_async_queue_timeout_pop (libglib-2.0.so.0)
                        #4  0x00007fc28d58e541 n/a (libglib-2.0.so.0)
                        #5  0x00007fc28d58da2a n/a (libglib-2.0.so.0)
                        #6  0x00007fc28cbb1075 start_thread (libpthread.so.0)
                        #7  0x00007fc28cec053f __clone (libc.so.6)

Starting the demo agent manually appears to fix the crashing issue, although now every time I start redshift, I get a notification asking if I'd like to allow it to access my location.

EDIT: Adding

[redshift]
allowed=true
system=false
users=

to the geoclue.conf appears to have fixed that as well. Working properly for me now.

@dsemi Probably the same as https://gitlab.freedesktop.org/geoclue/geoclue/issues/69 and since it happens on geoclue exiting, it's not as bad as it sounds. I really want to fix these bugs but I'm not paid to work on Geoclue currently.

See https://github.com/jonls/redshift/issues/636#issuecomment-407819140 for why you're being asked all the time. Your fix is a hack. I would suggest you instead shout at your DE to do the right thing or use a desktop that cares about your privacy (GNOME).

Anyway, this is not a redshift issue and discussion has continued here for long enough. If people have issues, please file issues/comment on geoclue: https://gitlab.freedesktop.org/geoclue/geoclue/issues . Thanks. Can someone from Redshift devs, close this issue?

I'm not so sure there isn't a redshift issue here as well as a geoclue issue. Like @dsemi, I'm using redshift without any DE, and in one of my many tests (probably using ltrace or strace) I got an indication that things were hanging when trying to update a status icon. No DE ==> No icon. I can't remember details of what I was trying - I just gave up because the hang occurred in a Python script and I don't know Python.

@stpeters00 if you are using geoclue from a console-only env, you are mostly likely the admin yourself and hence editing the config file is a completely ok solution: https://github.com/jonls/redshift/issues/636#issuecomment-409435222 . I had missed the fact that @dsemi is not using a DE, sorry. I'm not sure what you mean by no icon, geoclue doesn't require any icons or UI.

@zeenix About a week ago you posted "...geoclue (and other freedesktop.org software) rely on this compliance" where "this compliance" apparently meant XDG compliance. I read this as implying geoclue relies on there being a DE. That was reinforced by a lot of the chatter around geoclue and redshift issues involving various .desktop files, which should be irrelevant in the absence of a DE.

Note also that not having a DE does not imply console-only, unless you consider X plus a window manager to be a DE. I use X + fvwm to give me a setup with multiple virtual displays.

Editing config files is indeed acceptable for me if there's documentation to guide me, but having geoclue refuse to run for mysterious reasons is not ok. Fortunately, downgrading to 2.4.8 works for me, but someday a new release of geoclue might have something I want, so I see downgrading as a short-term workaround.

@dsemi

Same here for Arch:

$ pacman -Q geoclue2 redshift 
geoclue2 2.4.11-1
redshift 1.12-1

with

[redshift]
allowed=true
system=false
users=

inside geoclue.conf

@stpeters00 Well, I have nothing against people using whatever software or configuration they wish but please don't expect others to cater for your personal preferences. Having said that, I did not think about console-only setup with the recent changes (and neither did the other dev) and I apologize for that. The change to reject all clients when agent is not present, on it's own was needed to plug a security hole, where any client could get location w/o user's permission (or even worse: despite user have explicitly chosen not to give permission to the app in question) before an agent could be registered with geoclue. I should have provided a simple console-only agent (which would work for you too).

Same issue running i3wm and Manjaro, and the geoclue.conf didn't fix my issue

Same here.
Arch with 4.17.13-arch1-1-ARCH, and:

$ pacman -Q geoclue2 redshift 
geoclue2 2.4.11-1
redshift 1.12-2

And with:

[redshift]
allowed=true
system=false
users=

in the /etc/geoclue/geoclue.conf.
Doesn't work after the last upgrade.

P.S. Found a "solution": start the geoclue agent manually with /usr/lib/geoclue-2.0/demos/agent & (added it to my ~/.config/openbox/autostart), and now redshift works.

Please take a look at the comments posted by @zeenix above. In summary:

  • There is a bug in geoclue 2.4.10 that has been fixed in 2.4.11. You can also downgrade to 2.4.8 as a temporary workaround.
  • There's another minor bug in geoclue (https://gitlab.freedesktop.org/geoclue/geoclue/issues/69) that can happen when it shuts down but it doesn't prevent geoclue from working properly.
  • If you don't have a geoclue agent running, see the comments above or ask your distro/desktop environment to provide an agent (it is not a Redshift issue).
  • If you see other issues with geoclue, please report them to the geoclue project: https://gitlab.freedesktop.org/geoclue/geoclue/issues

UPDATE:
According to @zeenix the Geoclue authorization has been dropped for system (non-Flatpak) apps in Geoclue 2.5.0. See release notes and blog post.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

amosbird picture amosbird  路  4Comments

xxcriticxx picture xxcriticxx  路  3Comments

Powersource picture Powersource  路  4Comments

cbcoutinho picture cbcoutinho  路  6Comments

AdamNiederer picture AdamNiederer  路  5Comments