Unable to connect to GeoClue. Unable to get location from provider. #318
Comments
|
I've found location services had been turned off. After turning on location services redshift runs smoothly. It makes sense that redshift needs a location. However instead of exiting with a cryptic error message, redshift could display a dialog to manually set a location or turn on location services. For example gnome-maps doesn't crash when location services are not running:
See attached screen capture of gnome-maps: |
|
@DimitriPapadopoulos where can I "turn on location services" setting you are describing... gnome-maps doesn't work on 14.04. I presume there's an underlying package and not something inherently required about gnome-maps being installed to fix redshift's geoclue2 problems. |
|
Gnome maps is just an example of an alternative way to handle missing location services. Other than that it is totally unrelated to redshift. |
|
As far as I can tell it is quite difficult to disable intrusive services like geoclue (location service) in Ubuntu: My guess is that location services are not disabled on your Ubuntu computer. Also I have just tried an Ubuntu 14.04 workstation and gnome-maps works pretty well once installed. Something might be broken on your computer. |
|
I decided to just install the latest build 1.11 from source and specify my lat:lon manually in the config. Personally I don't travel with my workstation across time zones .... Like ever. So dynamic geoclue calls every time redshift starts aren't really worth the struggle to resolve. Thanks for the reply @DimitriPapadopoulos |
|
Was encountering this and have a clean fix. Installed redshift and redshift-gtk packages. Installed geoclue-2.0 Hope this helps someone else 🍻 |
|
@clayzermk1 |
|
At least in the .deb, it seems like |
|
@clayzermk1 thank you very much, helped me a lot. Worked perfectly for me, using Linux Mint 18 KDE |
ghost
mentioned this issue
|
@clayzermk1 it solved for me. thanks so much. |
|
I am still having this issue on Ubuntu 16.04. I have tried every solution advised in this thread to no avail. Any idea how I can troubleshoot this? |
|
Based on the original post, the
|
|
Ok, so it is not possible to run Redshift without location services? It would be nice to be able to set the location manualy (I think I know where I am:) ). I see it as the privacy issue. |
|
No you don't need any location service, simply pass |
|
On Fedora 28 KDE, only thing that worked was redshift-gtk -l 0:0 |
|
On Fedora 28 Cinammon, the command redshift-gtk -l 0:0 also works |
|
I had this issue as well, my environment is Fish > Tmux > Guake. I had to exit Tmux within Guake and run redshift outside of Tmux. I had tried creating a new window (shell session) inside Tmux but that didn't work. |
|
Getting almost the same error message in Debian too. geoclue-2.0 is installed. In the terminal, no gtk: sudo same: Was suggested to start service, no go: |
|
What version was merge request 6 merged into? Perhaps it will resolve the issue. FYI for Fedora 28 issue is 1585970. |
|
I'm getting this issue on KDE 5.13.3. When I log in, I get prompted to allow location access (not something I knew KDE did) but it doesn't seem to do anything. |
|
This seems like an issue with connectivity with the external server. The error handling needs to be better around refused connections. |
|
I'm using an Arch-based distro (Artix Linux actually - it uses OpenRC instead of SystemD) with XFCE4, and I get a prompt every time I sign in asking me whether I want redshift to be allowed to access my location. I found a |
|
I have the same problem on Arch inside KDE, I don't know how to enable location from KDE, since it seems like it's a GNOME thing. |
|
You need patched geoclue, and make sure geoclue demo agent is running. Agent will start geoclue on demand. |
|
I'm new to GitHub and I do not know how to post the error I have a problem starting Redshitf in Konsole: redshift -o. Waiting for the current location to be available ... Help me please :'v |
Where can I find this patched geoclue? Also, I'm unsure as to what you mean by |
|
@sbrl , read my last comment about bug fix. You need a version with the merge request applied. On Fedora 28 I'm using Fedora 29 latest Koji builds, see the bugzilla issue. The demo agent that is part of the GeoClue distribution needs to be started unless you are running Gnome. On Fedora 28 XFCE starts it automatically. No idea about other distros and/or DEs. |
|
@Rybec Rants such as "this just isn't very good software", "most of the world" or "if it actually worked, which it clearly doesn't" won't help. We're just end users like you trying to help. Besides, if I were the programmer, I would choose to ignore your rants. To the best of my knowledge, most Night Mode programs do have a mode based on suntime/sunset, and that is usually the default mode. Here are facts: That said, the transition might not occur precisely at sunset/sunrise - precisely depending on the location because as you wrote it might make less sense near the poles. And as I wrote, one can imagine an alternative mode where the transition occurs at a time specified by the user and not at sunset/sunrise time. Actually, most Night Mode programs out there do support that, including redshift as far as I can see (#529). The problem here is not the existence of two modes, based on:
The problem is that the default mode, based on sunset/sunrise time has problems retrieving the location and this breaks redshift. That the whole point of this issue. And yes, these problems really are a pain, hence the length of this page. I guess it's not easy to fix. |
|
First, Windows "sunset/sunrise" option uses set times for that, not actual sunset to sunrise. I've been using mostly Windows for the last year (and Windows on at least one computing for several), and on all three of the computers I used it on, the "sunset to sunrise" time was the same range, both for Idaho and for here in Alaska. It doesn't actually try to do sunset to sunrise. I was actually wrong above about Windows starting at 9pm. It starts at 7:30p for "sunset". I changed it to 9pm myself on all three systems. It did start at 7:30p for sunset to sunrise mode though, including on my new laptop, which I setup here in Alaska. Neither Mac nor Windows use your location data though. They use time zone (which may be set by location data, though not in my case, because I set my time zones manually and disabled the location tracking for Windows). Second, this is what the MS link you provided says, "Your display emits blue light—the kind of light you see during the day—which can keep you up at night. To help you get to sleep, turn on the night light and your display will show warmer colors at night that are easier on your eyes." I didn't realize Redshift was designed more to be novelty software to make it easier to work late into the night. I just went back and read the README, and it says that Redshift is designed purely to reduce eyestrain due to blue light at night. The issue is that other Night Mode software is designed for sleep, not eyestrain from working in the dark. As implied in the MS link, blue light signals your brain that it is still daytime, making it harder to sleep right after using computers. I assumed this was the intent of Redshift, but that clearly isn't the case. It is clear now that it is intended to make it easier to have poor sleep habits rather than as a help to maintain good sleep habits, and in that context, it does make sense to trigger on actual sunset. Third, yeah, it does appear to be hard to fix, though it wouldn't be hard to mitigate. A simple default of falling back on local time or just providing a manual button if location cannot be obtained would be pretty easy to implement. It looks like the developers just don't care, given how long this has been a problem. I do understand that it can be hard to keep up with open source projects. I run a few of my own. But if the owners and contributors of the project don't have time to continue maintaining it, it would be nice if they would at least make that known. (If I no longer had time to work on my own projects, I would certainly add a note at the top of the README for my repos, saying that they were no longer being actively maintained, because that's just good manners.) I would rather know a project is no longer being maintained than spend two hours searching for a solution to a problem that turns out to be 5+ years old. And maybe if the owners had said they weren't actively maintaining it anymore, Debian wouldn't be including such broken software in their repositories anymore. Had it not been available though apt-get, I wouldn't have wasted all of this time. (Though, to be fair, part of the fault here is with Debian, for not being thorough in their testing.) Anyhow, for anyone else (still reading after that wall of text...) who needs something like this but can't get Redshift to work, Debian, Ubuntu, and most other Debian based distros have a package called |
|
Still, I think most programs use or used to use sunset/sunrise time by default, most importantly f.lux which was the first mainstream night mode program, if I recall correctly, and probably the one redshift tried to mimic. But then both MacOS and Windows have ended up including their own utility. Not sure about macOS, but yes, on Windows Microsoft have chosen local time by default (transition to warmer 21:00-07:00 as you explained). And it's true Windows means "most users", at least as far as computers are concerned. By the way, I discovered Finally, I'm not certain redshift is not maintained anymore. It's just that this issue seems to be related to system peculiarities and geolocation servers not responding for some reason (maybe not easily available for free anymore). I spent some time looking into it a few years ago and the causes were multiple, depending on the Linux distribution and system parameters, although I cannot remember the details. Perhaps your suggestion to change to a default mode based on local time instead of sunset/sunrise time, like Windows, might be a good way to mitigate this issue. Why not create a new issue for that? |
|
Mac and Windows don't. They have "sunset to sunrise" settings, but they actually use time. I haven't tried f.lux, so you might be right there. As far as sct goes, I am currently considering writing a systemd service in Python that uses sct to achieve this functionality using local time. The one problem I have is that I hate GUI programming, and I don't think it would be ideal to require users to edit a config file to adjust the on/off times. That said, if I do this, I'll put it on Github, even if it doesn't have GUI configuration. Maybe I'll start with this and add GUI later, if I have time. I would say Redshift is unmaintained at this point, because the last commit was June 14th 2020. That was over year ago. That doesn't mean they can't start maintaining it again, but it does mean that for all intent the project is unmaintained. Using the the local time as the default would be an excellent idea, but if no one has worked on this in a year, and they didn't do that 5 years ago, when this issue started coming up, I don't see the point opening an issue for it. Clearly it's not a priority to make this more broadly usable, and the devs only care about the sunset/sunrise functionality and not the sleep applications, I can respect that (even if I don't agree with it). I'll post here if I end up writing that service, but it will have sct as a dependency. (Redshift has several backend options for adjusting color temperature. Maybe I could add that in the future, but right now, my priority is something that works for me, and if there is a good chance it will help others, I'm willing to release it under an open source license.) |
|
Also, Gnome and KDE now have their own built-in Night Light and Night Color, that's what I have been using for some time now. Their default is "sunset/sunrise" but it just works and might be actually based on fixed times instead of geolocation and actual sunset/sunrise times... |
|
Yeah, this is kind of a fringe thing at this point, because it is built in for most OSs and most desktop managers in Linux. I'm using Enlightenment, which does not have this feature. I did just finish rolling my own, and I even wrote a GUI config program. I was planning to do it as a service, but since different users might want different settings, I've decided to make a desktop autostart thing. I guess you won't need it, but I plan on putting it on Github sometime tomorrow. |
|
On Ubuntu 21.10 solved by installing girl1.2-geoclue-2.0, libgeloclue-2-0 and libgeocode-glib0, and adding coordinates into sudo nano /etc/geoclue/geoclue.conf. Not sure which of these fixed it but after installing these 3 redshift finally works. Alternatively, gammastep on Ubuntu is a clone of redshift that also worked also note that while the v1.12 change logs notes that the conf file location was changed from |
|
@gpioneer90 Which version of redshift is that? I have all these packages installed in Debian 10 and it does not work for me there, with redshift v. 1.12. |
1.12. Did you try making a config file in ~/.config/redshift.conf instead of ~/.config/redshift/redshift.conf ? (I made a typo in the above post for the directory, fixed it) if that doesn't work, see if gammastep is available to download in your repos because that worked out of the box for me |
|
i am just using qtile tiling manager and hence dont have any DEs for running the graphical redshift-gtk. though i could show some icons on the qtile bar, i tried to do make it work on the command line. still it did not work. then when i ran now need to figure out how to run it on the startup. ps: got my co-ordinates from google map. you should change it your location. |
|
Hi, And then run : systemctl enable geoclue.service That's it. It works fine now. Hope it could help someone. |
|
On 1/4/22 01:39, LambertCliff wrote:
Hi,
For me, the solution was the following :
My setup : Fedora 34 with Cinnamon (was working fine with Fedora 33
until the update to 34).
I realised that when I open my user session, the Geoclue Service isn't
yet running and so Redshift encounters a "timeout" to fetch the coordinates.
The workaround :
In the folder /usr/lib/systemd/system I edited the geoclue.service file
by adding at the bottom :
|[Install] WantedBy=multi-user.target |
And then run : *systemctl enable geoclue.service*
That's it.
It works fine now.
Hope it could help someone.
It did. Thank you!
I had to add a
# systemctl start geoclue.service
before redshift's call to geoclue would work:
$ redshift
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 500.
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.
After starting geoclue.service:
$ redshift
Waiting for initial location to become available...
Location: 38.83 N, 119.35 W
|
|
Geoclue worked for a week about three weeks ago. This happened after
running my dnf updates. Then after
another dnf updates, stopped.
It occurs to me that something is disabling
geoclue's service from starting after an update.
I do know that "some" developers think that it is
up to the user to figure out that he has to manually
troubleshoot and figure out on his own that he has
to enable and start the service after dnf installs
their program. It is is total pain in the neck. An
in my opinion should be done in the post install
scripts.
Maybe there is something in the "upgrade" pre or
post install scripts that is disabling the
geoclue.service?
|
|
For those with the following issue: If you just want a minimal install, then you can run the app like this instead: I'm using Fedora 35 LXDE. |
|
Hi All,
Fedora 35
redshift-1.12-13.fc35.x86_64
geoclue2-2.5.7-6.fc35.x86_64
If I manually start geoclue
# systemctl start geoclue.service
as root, redshift can communicate with
geoclue2 and redshift works fine.
But redshift can not start geoclue,
unless geoclue was started as root first:
$ redshift
Waiting for initial location to become available...
Unable to start GeoClue client:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied:
disallowed, no agent for UID 500.
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.
can not start geoclue as a standard user
(group = 100 or users=500).
I have redshift in /etc/geoclue/geoclue.conf:
[redshift]
allowed=true
system=false
users=
Tried "users=500" too.
Redshift is "suppose" to be able to start geoclue
manually as a user.
What gives?
Many thanks,
-T
|
|
Hi All,
I modified geoclue.service to keep geoclue running
in the background:
ExecStart=/usr/libexec/geoclue --timeout=0
Now it is working.
What needs to be fixed is to allow redshift to start
geoclue as a user so geoclue does not have to stay
running in the background.
…-T
modified /usr/lib/systemd/system/geoclue.service
[Unit]
Description=Location Lookup Service
[Service]
Type=dbus
BusName=org.freedesktop.GeoClue2
User=geoclue
# --timeout=0 mean never time out
ExecStart=/usr/libexec/geoclue --timeout=0
# Filesystem lockdown
ProtectSystem=strict
ProtectKernelTunables=true
ProtectControlGroups=true
ProtectHome=true
PrivateTmp=true
# Network
PrivateNetwork=false
# Execute Mappings
MemoryDenyWriteExecute=true
# Modules
ProtectKernelModules=true
# Real-time
RestrictRealtime=true
# Privilege escalation
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
|
|
I got this error and instead of having to install yet another program I put this snippet together |
|
To work around this issue, I've made the geoclue service autostart on In order to do that I've created the directory and file [Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable geoclue.service |
Yesterday I after restarting my linux at night I realized suddenly Redshift didn't detect my location. After morning to evening I reinstalled Redshift and changed the geoclue.conf configuration to no avail. instead there is a "Timeout was reached" error message when I run the sudo timeshift command in the terminal. |
|
@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running For details, refer to the redshift page on Archwiki. |
Yes. At that time the geoclue agent was already in the Startup list. It turns out that the cause is because the internet connection at home is not reliable. (which I remember at that time) |
Can confirm on Ubuntu 22.04 solved with running an agent. |
On Debian you put the file here .config/redshift.conf and not ./config/redshift/redshift.conf |
|
On Debian same problem: |
|
In my case the problem was two-fold on Ubuntu 22.04 LTS. I had the described problem with geoclue2 and tried overriding this in However, it seemed like all configuration settings were ignored and it still tried to contact the geoclue2 service, which is not running. The problem was that my The real fix for me was to allow access to my configuration file in the apparmor profile. Maybe this also helps others. |
Thanks, work in Linux Mint 21 Vanessa using Fluxbox Window Manager. I found the latitude and longitude in: https://www.geodatos.net/ |
This is what did it for me, only on Ubuntu 22 it was at |
|
Since this is still open, and it seems to be some obscure issue on Debian + XFCE especially, something is using wayland in debian XFCE. I've read it's lightDM but not sure, tried to solve it. So, I went ahead and wrote a little script that uses xsct wrapped with yad to provide a super simple screen red light alternative https://github.com/fonzi/bash-tools/tree/master/debian/screen-temp |
|
Main issue is that redshift depends on geoclue running see previous comments. above. |
and others
Unable to start redshift 1.11 on Fedora 23 since yesterday:
This is similar to #158 but the proper fix - having both
redshift.desktopandredshift-gtk.desktopfiles - doesn't help any more. Indeed both files are available in Fedora since #1309177 was closed:Both alternative solutions work although they are supposed to be bad solutions:
sudo redshift-gtk/etc/geoclue/geoclue.conf:The text was updated successfully, but these errors were encountered: