Redshift: Redshift fails to run with GeoClue 2.5.7

[freedomd1v3]

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 get the same error when running redshift-gtk. Running from both root and sudo also doesn't work. Same with editing /etc/geoclue/geoclue.conf.

• I have checked the FAQ (https://github.com/jonls/redshift/blob/master/README.md#faq) before opening the bug report and my issue is not mentioned there.

To Reproduce
Steps to reproduce the behavior:

1. Update GeoClue to 2.5.7(-2 in my case).
2. Try to run Redshift.
3. Done.

Expected behavior
Program uses GeoClue to successfully find the location and apply required screen color.

Software versions

• OS: Linux
• Redshift version: 1.12
• Distribution: Arch Linux
• Redshift installed from: official "Community" repository

[mosbasik]

Same experience as OP, using same distro and versions for redshift and geoclue.

Additional note: when redshift-gtk fails and opens the window showing the error message, the process immediately pegs my CPU until the window is closed.

If the the overall issue is fixable on the redshift side (since I don't know if the problem is with redshift or geoclue) it'd be awesome if the redshift-gtk failure could also made more polite!

[mosbasik]

Looks like #794 is caused by the same issue.

796 _might_ be the same issue? - error message not identical, but quite similar.

[mosbasik]

Did more googling this morning. I found a lot of red herrings, mostly involving geoclue's default API key to Mozilla Location Services being ratelimited (there _is_ a plan to phase out the default key in favor of distro keys, but it hasn't gotten to the first deprecation step yet and so can't be the cause here).

Of course the Arch Wiki has instructions for this situation: Redshift / Troubleshooting / Redshift GDBus.Error:org.freedesktop.DBus.Error.AccessDenied on start. TLDR: make a systemd user service to start the geoclue demo agent.

From the Arch forums:

geoclue2 2.4.10 requires an agent to be running because of this commit.

If [the method with which you launch] X does not start /etc/xdg/autostart/geoclue-demo-agent.desktop, or is not gnome, then you now need to manually start /usr/lib/geoclue-2.0/demos/agent when X is started.

I've been using i3wm for years and pretty sure I haven't been launching agent until now. The linked commit is 2 years old; I haven't yet figured out which geoclue change in the upgrade I did yesterday would suddenly force me to run the agent:

/var/log/pacman.log:

[2021-01-28T10:48:23+0100] [ALPM] upgraded geoclue (2.5.6-1 -> 2.5.7-2)

But apparently I'm not the only one for whom something changed recently; I found this geoclue issue opened 8 hours ago: Running demo failed (access denied). It describes the same error that @freedomd1v3 describes in our OP. If I start agent first, the where-am-i described in that issue succeeds.

A redshift user who began manually running agent kept getting notifications asking whether it's ok to tell redshift their location, then silenced them by adding the following to /etc/geoclue/geoclue.conf:

[redshift]
allowed=true
system=false
users=

The geoclue maintainer says the approach described above is a hacky solution caused by agent being a demo agent that geoclue provides as an example; the intent is for the DE to provide its own geolocation agent (which could then presumably remember which apps the user has already granted location permissions to).

I don't use a DE, so I'll use the geoclue demo agent I guess.

[freedomd1v3]

Did more googling this morning. I found a lot of red herrings, mostly involving geoclue's default API key to Mozilla Location Services being ratelimited (there _is_ a plan to phase out the default key in favor of distro keys, but it hasn't gotten to the first deprecation step yet and so can't be the cause here).

Of course the Arch Wiki has instructions for this situation: Redshift / Troubleshooting / Redshift GDBus.Error:org.freedesktop.DBus.Error.AccessDenied on start. TLDR: make a systemd user service to start the geoclue demo agent.

From the Arch forums:

geoclue2 2.4.10 requires an agent to be running because of this commit.
If [the method with which you launch] X does not start /etc/xdg/autostart/geoclue-demo-agent.desktop, or is not gnome, then you now need to manually start /usr/lib/geoclue-2.0/demos/agent when X is started.

I've been using i3wm for years and pretty sure I haven't been launching agent until now. The linked commit is 2 years old; I haven't yet figured out which geoclue change in the upgrade I did yesterday would suddenly force me to run the agent:

/var/log/pacman.log:

[2021-01-28T10:48:23+0100] [ALPM] upgraded geoclue (2.5.6-1 -> 2.5.7-2)

But apparently I'm not the only one for whom something changed recently; I found this geoclue issue opened 8 hours ago: Running demo failed (access denied). It describes the same error that @freedomd1v3 describes in our OP. If I start agent first, the where-am-i described in that issue succeeds.

A redshift user who began manually running agent kept getting notifications asking whether it's ok to tell redshift their location, then silenced them by adding the following to /etc/geoclue/geoclue.conf:

[redshift]
allowed=true
system=false
users=

The geoclue maintainer says the approach described above is a hacky solution caused by agent being a demo agent that geoclue provides as an example; the intent is for the DE to provide its own geolocation agent (which could then presumably remember which apps the user has already granted location permissions to).

I don't use a DE, so I'll use the geoclue demo agent I guess.

I also use i3wm instead of any other DE and the solution from ArchWiki works perfectly fine. I don't get how I forgot to check it in the first place...

The only thing for me is that geoclue doesn't tell me for granting any location access. Providing a systemd user unit just works out of the box without editing /etc/geoclue/geoclue.conf

Anyway, I think I'll stick to this solution for the time being. I also don't think it's really a redshift issue anymore, since it's up to DE to provide the authentication agent, while WM shouldn't even care about doing it. Therefore I'm closing this bug report. Thanks for help.