redshift
redshift copied to clipboard
On a wired connection geoclue is unable to determine current location
Describe the bug On a wired connection geoclue is unable to determine current location. It prompts an error. The cause for that is upstream and can be viewed here. Because I am not familiar with programming with GNOME applications I am posting this issue, so maybe someone with expertise in it will look and give the folks at freedesktop a hand.
- [x] I have checked the FAQ and my issue is not mention there.
To Reproduce Steps to reproduce the behavior:
- Connect Ethernet cable to the device
- Launch redshift
Expected behavior Normal behavior and no errors
Error output/logs/screenshots
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.
Software versions (please complete the following information):
- OS: Linux
- Redshift version: 1.12
- Distribution: Arch
- Redshift installed from: pacman
I'm also having the same issue. Except, geoclue is unable to determine location on any network, wired or wireless.
It looks like we all have the same problem. After a recent update, I get this error:
$ env LANGUAGE=en_US.UTF-8 redshift
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.$ inxi -F
System:
Host: debian-home Kernel: 4.19.0-14-amd64 x86_64 bits: 64 compiler: gcc
v: 8.3.0 Desktop: Gnome 3.30.2 Distro: Debian GNU/Linux 10 (buster)
Machine:
Type: Desktop Mobo: MSI model: B75MA-E33 (MS-7808) v: 1.0 serial:
So there are two workarounds that i saw about this :
/usr/lib/geoclue-2.0/demos/agent &
If you run tihs beforehand , or have some script that launches this on boot , redshift should work again, the annoying thing was the recommended solution for this issue which was :
[redshift]
allowed=true
system=false
users=
in your geoclue.conf did not work , though the script method , where you have agent & [and] redshift - that should work
the second one, could just be manual config , where you do
redshift -l Location
For me currently i just made a quick script that runs on boot , and it works fine : ) hope that helped out .
I decided to manually create the file ~/.config/redshift/redshift.conf
Followed instructions on https://wiki.archlinux.org/index.php/Redshift
It's strange that this worked without problems for several months without manual intervention. And then suddenly it broke.
Using the same solution as @williamson91. The commits that introduced the regression upstream clearly show why it regressed. However, repairing it may be more convolved.
I met this issue in a wireless network and decided to switch the manual geolocation. I think the dependency on geoclue2 is good for automation, but we need a safe fallback if the service fails. If possible, we can consider saving the lat and long in the config when the geoclue2 works. Later when the service fails, just use them as a fallback