Unable to connect to GeoClue. Unable to get location from provider.

[DimitriPapadopoulos]

Unable to start redshift 1.11 on Fedora 23 since yesterday:

$ redshift
Trying location provider `geoclue2'...
Using provider `geoclue2'.
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 1000.
Unable to connect to GeoClue.
Unable to get location from provider.
$ 

This is similar to #158 but the proper fix - having both redshift.desktop and redshift-gtk.desktop files - doesn't help any more. Indeed both files are available in Fedora since #1309177 was closed:

$ rpm -qf /usr/share/applications/redshift.desktop
redshift-1.11-1.fc23.x86_64
$ rpm -qf /usr/share/applications/redshift-gtk.desktop
redshift-gtk-1.11-1.fc23.x86_64
$ 

Both alternative solutions work although they are supposed to be bad solutions:

1. Run as sudo redshift-gtk
2. Add to /etc/geoclue/geoclue.conf:

[redshift]
allowed=true
system=false
users=

[sbrl]

Cool, @pastet89! I think I might have to do something like that myself on my Ubuntu 18.10 machine - the new dialog is really starting to annoy me....

I commented on your script here if you're interested - I had a few ideas :P

[IkeKap]

I second having this issue in 18.10 . Specifically, in kde plasma. Setting a location manually seems to do the trick just fine, but whenever I try switching it to automatic mode it glitches out. More specifically it asks for permission to use my location but doesn't give me enough time to register my "allow" click.

[Scafir]

After some messing around, I found that uninstalling all geoclues occurences and reinstalling geoclue-2.0 fixes this problem in ubuntu 18.10

[Mebus]

https://got-tty.org/fedora-redshifts-geoclue-error

Mebus

[sbrl]

@Mebus: That's in a language I don't understand. Sorry!

[Farcrada]

For those still on this; I fleshed out the config file's options over at https://github.com/jonls/redshift/wiki/Configuration-file

My current config looks like this:

[redshift]
location-provider=manual
[manual]
lon=62.7363138
lat=15.3654696

Works, but isn't ideal. A pop-up after ~10 seconds of being unable to get a response from GeoClue2 containing the option to insert values which puts it into the config would be nice. Maybe a one-time pop-up in which you can set it to system time/-zone or insert custom location settings.

[goekce]

Archlinux here. The problem was in my case that the key for mozilla geolocation had exceeded its daily limit, you can try yourself by getting your location manually:

https://location.services.mozilla.com/v1/geolocate?key=geoclue

In my case I get a JSON file with:

message | "You have exceeded your daily limit."

After changing the key in /etc/geoclue/geoclue.conf geoclue to test redshift works:

url=https://location.services.mozilla.com/v1/geolocate?key=test

I do not have any redshift config file other than ~/.config/systemd/user/redshift.service.d/display.conf (for setting DISPLAY=:0) nor application configuration for redshift in /etc/geoclue/geoclue.conf. I also do not have to start the geoclue agent.

[ArchangeGabriel]

@goekce Yeah, we changed the key from ArchLinux specific one to geoclue because the first had started being rate-limited, but seems geoclue one is now rate-limited too.

[ghost]

this is working in Fedora 30 with redshift-gtk-1.12-3.fc30.x86_64.

[LinuxOnTheDesktop]

I have Redshift 1.12 on Linux Mint 20. Running Redshift produces, Waiting for initial location to become available... This is strange, for the following reasons.

• I have geoclue-2.0 installed.
• I have Redshift, via it conf file, to set location manually (location-provider=manual).
• I have ammended the geoclue.conf file to allow Redshift.

Also:

• Even redshift -l 59.33258:18 yields Waiting for initial location to become available... though the next line of output is: Location: 59.33 N, 18.00 E.
• Before I moved from Mint 19.3 to Mint 20, Redshift worked.

[grindhold]

i had this problem just now under debian testing after upgrading. in started redshift-gtk with my window manager with the following commandline:

$ redshift-gtk -l mylat:mylon

until recently, redshift apparently assumed that one would like to select the manual location provider if one provided coordinates. or it was plainly the default. turns out specifying the provider manually solves the problem. it looks weird but it works for me:

$ redshift-gtk -l manual -l mylat:mylon

[LinuxOnTheDesktop]

Perhaps I miss something, but seemingly this fairly gross bug has existed in one form or another for four years - that is how old this ticket is.

[CarloNicolini]

Still present in Linux Mint 20 redshift package too.

[ishipilov]

i get location error too. but only on wifi when use wired connection redshift updates location and keeps it manjaro xfce

[thriveth]

I get the same since today, using Debian 10 (Stable).

I also get the Exceeded Daily Limit JSON file when trying manually at Mozilla. Is there any way to get around this?

[hdhruna]

Anyone facing issues, remove geoclue package and install geoclue2-2.5.2-2 for the time being.

[djearthquake]

Error:

"GDBus.Error:org.freedesktop.DBus.Error.AccessDenied"

Fix:

• Update /etc/geoclue/geoclue.conf.
• Update whitelist and make an entry for org.

whitelist=org.freedesktop.DBus;_geoclue-demo-agent;gnome-shell;io.elementary.desktop.agent-geoclue2

[org.freedesktop.DBus]
allowed=true
system=true
users=

Pushing 'Location services' to the point of app failure and not including anything other than gnome desktop makes this poorly coded. Anybody can hit a button to make the desktop yellow. My advice is to leave a fail-safe in when you add features like Geo. That means do not push it especially if you are unable to support it for half a decade.

[Rybec]

@djearthquake Even that didn't work for me. And yeah, this is pretty shameful. The worst case scenario should be that it runs without location information, and the user can manually click a button to enable or disable night mode (or better yet, choose a time zone from a drop down, in the settings). I shouldn't have to look up my longitude and latitude to make such trivial software work, and quite honestly, I am confused as to why it can't just use the time locale data I set when I installed Debian.

Check this out, when I run "date" in a terminal, as a normal user, this is the result:

Mon 21 Jun 2021 12:41:58 AM AKDT

Notice that this has the time (yeah, I am up kinda late) and the time zone! Why does this need a totally separate service that has been known to be buggy for half a decade, when a simple user space command line tool can do it far more reliably?

[DimitriPapadopoulos]

@Rybec Time zone is irrelevant, redshift requires the location.

[Rybec]

Yes, that's a bug.

The point of Redshift (unless it has a different purpose from every other Night Mode thing out there) is to shift the screen color temperature after a certain time, so that the blue light doesn't interfere with sleep schedule. So it should be basing its functionality on time, and that's why timezone is important. I assume it is using location to determine time zone and/or time, since that's the purpose, and getting the time zone from the system _doesn't require location, thus it is over-complicating a very simple application to need location at all,

[DimitriPapadopoulos]

@Rybec The time zone as such is irrelevant. As you write, date or its programmatic equivalent will give the local time. No need to mess with time zones to retrieve time.

The point of most Night Mode things out there is to shift the screen colour temperature not after a certain time, but around sunset. So, redshift requires sunset/sunrise time, which depends on the location, not directly on the time zone.

One could imagine a simplified mode where the decision is taken on a time specified by the user and not on sunset/sunrise time. However, that's not what most Night Mode things out there do. It would be seen as a regression.

[majutsushi]

The decision of when to enable/disable night mode is based on sunset/sunrise times, and the time zone is not enough to determine those. People at the equator and near one of the poles are going to see the sun set and rise at very different times, even if they are in the same time zone.

[Rybec]

Then this just isn't very good software. I am one of those people near the poles, and basing this on my sunset time makes it utterly useless.

Most Night Mode programs (like those on iOS and Windows) do use time, because people in offset timezones or extreme latitudes are more interested in time than sunset. The idea is to time it based on when people want to go to bed, not on when the sun sets. Otherwise it wouldn't work at all in Alaska (where I actually live), where sunset right now is 11:45pm, and in the middle of winter, it is around 5pm. (And in Fairbanks, there's a week or two in summer where the sun doesn't set and a couple weeks in winter, where it never comes up.) Windows turns on night mode at 9pm, almost 3 hours before sunset here. So no, most Night Mode things don't use sunset, because that wouldn't be very useful to anyone.

I guess some people might think lining up your computer with actual sunset is cool, but most of the world bases bedtimes and waking times on local time, not on sunset. So all this is, is kind of cool. Or at least, it might be, if it actually worked, which it clearly doesn't. It isn't very useful though. It turns out it is easier to get what I need using sct, which is available in most Debian based distros and actually works. I should be able to just setup cron jobs to run it an hour before bedtime and then reset it around 7am and get better results than Redshift would give me even if it did work.

[DimitriPapadopoulos]

@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:

• Set your display for night time in Windows 10
• Use Night Shift on your Mac
• f.lux

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:

• time defined by the user,
• sunset/sunrise time.

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.

[Rybec]

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 sct. This can be used to change the color temperature of the screen. For night mode, run sct 4500 (or somewhere within a few hundred of 4500). To return to day mode, run sct or sct 6500. (6500 is the default, so running sct by itself goes to 6500.) According to sct, you can do anything from 1000 to 10000, so you can pick what works best. If you need it timed, you can use cron, anacron, or any other task scheduling software available for your distro. (Note that sct isn't persistent. So if you reboot, you will be back at 6500...at least, unless you have some boot script that runs sct...)

[DimitriPapadopoulos]

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 sct thanks to your post, indeed it's simple and just works. But it requires skills such as setting up a crontab, skills some users don't have. Actually, it looks like redshift merely provides a GUI around sct or the equivalent function calls, with two modes, based on sunset/sunrise time or based on a default or user-set local time. Both are interesting, so the question might be, which one should be the default?

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?

[Rybec]

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.)

[DimitriPapadopoulos]

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...

[Rybec]

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.

[ghost]

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 ~/.config/redshift.conf to ~/.config/redshift/redshift.conf, this doesn't appear to be the case.... create and make changes to ~/.config/redshift.conf for things like lat/long and color temps to be read

[thriveth]

@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.

[ghost]

@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

[pannet1]

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. i created a redshift configuration file manually like so

[redshift]
location-provider=manual
[manual]
lon=60
lat=6

still it did not work. then when i ran redshift -c ~/.config/redshift.conf it worked. hope this helps someone.

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.

[LambertCliff]

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.

[ToddAndMargo]

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

[ToddAndMargo]

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?

[pguerin3]

For those with the following issue:

> 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.
> 

If you just want a minimal install, then you can run the app like this instead:

> redshift -l manual -l -24.43:100.85
Using method `randr'.
Waiting for initial location to become available...
Location: 24.43 S, 100.85 E

I'm using Fedora 35 LXDE. Hope this helps anyone trying to do some troubleshooting.

[ToddAndMargo]

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

[ToddAndMargo]

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

[jakob1379]

I got this error and instead of having to install yet another program I put this snippet together

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

if [ ! -z "$(pgrep redshift)" ]; then
    killall redshift
    wait
fi

gpsinfo="$(curl -s ipinfo.io | sed 's/[" ]//g')"
lat=$(echo "$gpsinfo" | awk -F '[:,]' '/loc/{print $2}')
lon=$(echo "$gpsinfo" | awk -F '[:,]' '/loc/{print $3}')

redshift-gtk -l $lat:$lon 2>/dev/null &

[mhitza]

To work around this issue, I've made the geoclue service autostart on multi-user.target (graphical.target definitely should work as well).

In order to do that I've created the directory and file /etc/systemd/system/geoclue.service.d/multi-user.conf (a systemd drop-in file/override) with the following content.

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable geoclue.service

[Reno-Sifana]

Based on the original post, the geo2 location provider is already installed. So there are two solutions to this:

1. Run Redshift from command line as root **`sudo redshift`**

2. Turn on Location services: Goto **Settings --> Privacy --> Location Services (ON/OFF)**

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. Desktop Environment: Xfce

[goekce]

@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running /usr/lib/geoclue-2.0/demos/agent in the background.

For details, refer to the redshift page on Archwiki.

[Reno-Sifana]

@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running /usr/lib/geoclue-2.0/demos/agent in the background.

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)

[paxapy]

@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running /usr/lib/geoclue-2.0/demos/agent in the background.

For details, refer to the redshift page on Archwiki.

Can confirm on Ubuntu 22.04 solved with running an agent. Had to add it to autorun.. Yet I prefer manually setting lon/lat but it seems like .config/redshift/redshift.conf ignored when installing as regular package.

[DeeDeeRanged]

@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running /usr/lib/geoclue-2.0/demos/agent in the background. For details, refer to the redshift page on Archwiki.

Can confirm on Ubuntu 22.04 solved with running an agent. Had to add it to autorun.. Yet I prefer manually setting lon/lat but it seems like .config/redshift/redshift.conf ignored when installing as regular package.

On Debian you put the file here .config/redshift.conf and not ./config/redshift/redshift.conf This is mentioned in the man redshift.

[TomaszWaszczyk]

On Debian same problem:

Trying location provider `geoclue2'...
Using provider `geoclue2'.
Could not connect to wayland display, exiting.
Failed to start adjustment method wayland.
Trying next method...
Using method `randr'.
Waiting for initial location to become available...

[raimue]

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 ~/.config/redshift.conf like this:

[redshift]
location-provider=manual
[manual]
lon=42
lat=23

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 ~/.config/redshift.conf was a symlink to the real path ~/dotfiles/.config/redshift.conf. This caused a permission denied error that was also reproducable using redshift -c ~/dotfiles/.config/redshift.conf. The access was denied by apparmor, which is enabled by default on Ubuntu.

The real fix for me was to allow access to my configuration file in the apparmor profile. Maybe this also helps others.

--- a/apparmor.d/usr.bin.redshift
+++ b/apparmor.d/usr.bin.redshift
@@ -39,2 +39,3 @@
   owner @{HOME}/.config/redshift.conf r,
+  owner @{HOME}/dotfiles/.config/redshift.conf r,
   owner /run/user/*/redshift-shared-* rw,

[wachin]

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 ~/.config/redshift.conf like this:

[redshift]
location-provider=manual
[manual]
lon=42
lat=23

Thanks, work in Linux Mint 21 Vanessa using Fluxbox Window Manager. I found the latitude and longitude in: https://www.geodatos.net/

[tremby]

@Reno-Sifana I had the same output on Archlinux using i3. I solved it by running /usr/lib/geoclue-2.0/demos/agent in the background.

For details, refer to the redshift page on Archwiki.

This is what did it for me, only on Ubuntu 22 it was at /usr/libexec/geoclue-2.0/demos/agent.