Bug#892275: redshift: Unable to connect to GeoClue
> * Paul Gevers [210526 21:49]: > > On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville > > wrote: > > > IMVHO, you should remove the redshift systemd file and let redshift > > > start via de xdg autostart mechanism. The geoclue agent should then be > > > started before redshift as I think it start the process using the > > > alphabetical order. > Maybe someone can come up with a patch that works on both, systemd and > non-systemd systems? If thats even relevant in the first place... As there's no non-systemd specific code in redshift at all, yet it works fine for me, why would that systemd support be needed either? Meow. -- ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Bug#892275: redshift: Unable to connect to GeoClue
* Paul Gevers [210526 21:49]: > On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville > wrote: > > IMVHO, you should remove the redshift systemd file and let redshift > > start via de xdg autostart mechanism. The geoclue agent should then be > > started before redshift as I think it start the process using the > > alphabetical order. > > So, I think reassigning back to redshift makes most sense after this > assessment (which makes sense to me, albeit being non-expert). Maybe someone can come up with a patch that works on both, systemd and non-systemd systems? If thats even relevant in the first place... Chris
Bug#892275: redshift: Unable to connect to GeoClue
Control: reassign -1 redshift 1.11-1 Control: retitle -1 redshift shouldn't start itself via systemd Hi, On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville wrote: > IMVHO, you should remove the redshift systemd file and let redshift > start via de xdg autostart mechanism. The geoclue agent should then be > started before redshift as I think it start the process using the > alphabetical order. So, I think reassigning back to redshift makes most sense after this assessment (which makes sense to me, albeit being non-expert). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#892275: redshift: Unable to connect to GeoClue.
On Mon, 1 Feb 2021, at 19:30, nicoo wrote: > Could you check the following two things for me? > > 1. Does redshift work in “manual” mode, i.e. providing it with latitude and >longitude? That could be a workaround, as you can pass it `-l LAT:LON` on >the command line, or set it in ~/.config/redshift.conf like so: > > [redshift] > location-provider=manual > > [manual] > lat=12.34 > lon=56.78 It does: both `redshift-gtk -l 48.86:2.35` and `redshift -l 48.86:2.35` work correctly. Putting the setting in redshift.conf works as well. > 2. Is the AppArmor profile denying any actions from redshift? >You should be able to find the relevant logs in /var/log/audit.log >if you install/enable auditd. I've seen bug reports about redshift and AppArmor but that doesn't seem related. I tried `apt-get install auditd`, followed by `redshift` (which failed with the GeoClue error), but nothing related to redshift or geoclue showed up in audit.log. Thanks for your help, -- Gabriel Kerneis
Bug#892275: redshift: Unable to connect to GeoClue
On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville wrote: > The problem is that the geoclue agent is started via a xdg autostart > file and redshift is started via a systemd user file meaning that the > ordering between these two is uncertain. Thank you for your advice. It's useful for me as i3 window manager. I can just use redshift on Debian sid as following: ``` $ sudo apt install redshift-gtk $ grep autostart ~/.i3/config | tail -1 exec ~/.i3/autostart $ head -1 ~/.i3/autostart /usr/libexec/geoclue-2.0/demos/agent & ``` Best regards, -- Kiwamu Okabe
Bug#892275: redshift: Unable to connect to GeoClue
Hello, The problem here is that refshift is started before the geoclue agent is started. gnome-shell implements its own agent so that always work for people using GNOME. For people not using GNOME (or no DE at all) you need to have the geoclue agent running before doing any location query. The problem is that the geoclue agent is started via a xdg autostart file and redshift is started via a systemd user file meaning that the ordering between these two is uncertain. Moreover, using systemd to start redshift (as it requires an X display) is also feels wrong to as system will try to start it even when the user is logged in on a terminal/without X IMVHO, you should remove the redshift systemd file and let redshift start via de xdg autostart mechanism. The geoclue agent should then be started before redshift as I think it start the process using the alphabetical order. Kind regards, Laurent Bigonville
Bug#892275: redshift: Unable to connect to GeoClue.
Hi Nicoo, thanks for looking into this. On Mo 01 Feb 2021 19:30:11 CET, nicoo wrote: Control: reassign -1 geoclue-2.0 Control: affects -1 redshift Hi Gabriel, Mike, and Nicolas, On Thu, Jan 07, 2021 at 09:14:46PM +, Mike Gabriel wrote: On Do 07 Jan 2021 22:03:11 CET, Debian Bug Tracking System wrote: > Package: redshift-gtk > Version: 1.12-4 > Followup-For: Bug #892275 > > Dear Maintainer, > > It seems that I have the same bug since today's reboot. > See the attached screenshot. > Moreover, I can't stop redshift. I close the window and it comes back. > I can't stop it, even killing it makes the fatal window come back again. > redshift uses 100% of a processor. > > Yours, > n. I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to 2.5.7-2, gtk-redshift is broken (again). Urg. I'm really sorry you all were affected by this issue. Could you check the following two things for me? 1. Does redshift work in “manual” mode, i.e. providing it with latitude and longitude? That could be a workaround, as you can pass it `-l LAT:LON` on the command line, or set it in ~/.config/redshift.conf like so: [redshift] location-provider=manual [manual] lat=12.34 lon=56.78 As the Debian softfreeze is ahead, I am currently super-busy. I can test this after the freeze. Sorry. 2. Is the AppArmor profile denying any actions from redshift? You should be able to find the relevant logs in /var/log/audit.log if you install/enable auditd. For some days now, redshift is unusable, thus bumping severity to grave again. Also, the upstream activity of redshift is suboptimal. Many open PRs, last activity dates back to summer 2020. :-( Yes. I'm also pretty unimpressed with the size of d/patches by now. >_>' I'm hopeful, though, as upstream mentionned resuming maintaining maintainance of it, so there might be an upswing in activity. This sounds like something to grasp to, indeed. Thanks for looking after redshift in Debian. Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpEp3T9Lsh0J.pgp Description: Digitale PGP-Signatur
Bug#892275: redshift: Unable to connect to GeoClue.
Control: reassign -1 geoclue-2.0 Control: affects -1 redshift Hi Gabriel, Mike, and Nicolas, On Thu, Jan 07, 2021 at 09:14:46PM +, Mike Gabriel wrote: > On Do 07 Jan 2021 22:03:11 CET, Debian Bug Tracking System wrote: > > > Package: redshift-gtk > > Version: 1.12-4 > > Followup-For: Bug #892275 > > > > Dear Maintainer, > > > > It seems that I have the same bug since today's reboot. > > See the attached screenshot. > > Moreover, I can't stop redshift. I close the window and it comes back. > > I can't stop it, even killing it makes the fatal window come back again. > > redshift uses 100% of a processor. > > > > Yours, > > n. > > I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to 2.5.7-2, > gtk-redshift is broken (again). Urg. I'm really sorry you all were affected by this issue. Could you check the following two things for me? 1. Does redshift work in “manual” mode, i.e. providing it with latitude and longitude? That could be a workaround, as you can pass it `-l LAT:LON` on the command line, or set it in ~/.config/redshift.conf like so: [redshift] location-provider=manual [manual] lat=12.34 lon=56.78 2. Is the AppArmor profile denying any actions from redshift? You should be able to find the relevant logs in /var/log/audit.log if you install/enable auditd. > For some days now, redshift is unusable, thus bumping severity to grave > again. Also, the upstream activity of redshift is suboptimal. Many open PRs, > last activity dates back to summer 2020. :-( Yes. I'm also pretty unimpressed with the size of d/patches by now. >_>' I'm hopeful, though, as upstream mentionned resuming maintaining maintainance of it, so there might be an upswing in activity. Best, nicoo signature.asc Description: PGP signature
Bug#892275: redshift: Unable to connect to GeoClue.
Package: redshift Version: 1.12-4 Followup-For: Bug #892275 X-Debbugs-Cc: witold.bary...@gmail.com I believe it was working before. Now it fails for me too on log in with a dialog showing it can't connect to geoclue. user@debian:~$ systemctl --user status redshift ● redshift.service - Redshift display colour temperature adjustment Loaded: loaded (/usr/lib/systemd/user/redshift.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2021-01-20 01:46:56 UTC; 33min ago Docs: http://jonls.dk/redshift/ Process: 2367 ExecStart=/usr/bin/redshift (code=exited, status=1/FAILURE) Main PID: 2367 (code=exited, status=1/FAILURE) CPU: 4ms Jan 20 01:46:56 debian systemd[2275]: redshift.service: Scheduled restart job, restart counter is at 5. Jan 20 01:46:56 debian systemd[2275]: Stopped Redshift display colour temperature adjustment. Jan 20 01:46:56 debian systemd[2275]: redshift.service: Start request repeated too quickly. Jan 20 01:46:56 debian systemd[2275]: redshift.service: Failed with result 'exit-code'. Jan 20 01:46:56 debian systemd[2275]: Failed to start Redshift display colour temperature adjustment. user@debian:~$ $ pgrep -a redshift 2972 /usr/bin/python3 /usr/bin/redshift-gtk 2973 /usr/bin/redshift -v $ This is a default install of packages, on a clean system. $ dpkg -l | grep geoclue ii geoclue-2-demo 2.5.7-2 amd64geoinformation service (demonstration programs) ii geoclue-2.0 2.5.7-2 amd64geoinformation service ii libgeoclue-2-0:amd642.5.7-2 amd64convenience library to interact with geoinformation service $ Screenshot in the attachment. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages redshift depends on: ii init-system-helpers 1.60 ii libc62.31-9 ii libdrm2 2.4.103-2 ii libglib2.0-0 2.66.4-1 ii libwayland-client0 1.18.0-2~exp1.1 ii libx11-6 2:1.7.0-2 ii libxcb-randr01.14-2.1 ii libxcb1 1.14-2.1 ii libxxf86vm1 1:1.1.4-1+b2 Versions of packages redshift recommends: ii geoclue-2.0 2.5.7-2 redshift suggests no packages. -- no debconf information
Bug#892275: redshift: Unable to connect to GeoClue.
Le Thu, Jan 07, 2021 at 09:14:46PM +, Mike Gabriel a écrit :
> I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to 2.5.7-2,
> gtk-redshift is broken (again).
I can confirm as well.
> user@host#:~ kill -9 `ps aux | grep redshift | grep -v grep | awk '{ print
> $2 }'`
Also in my case I found useful to remove
~/.config/autostart/redshift-gtk.desktop and to disable the service in
systemd which (according to pstree) was responsible for launching it:
$ systemctl --user disable redshift
$ systemctl --user disable redshift-gtk
Gabriel
Bug#892275: redshift: Unable to connect to GeoClue.
Control: severity -1 grave
Hi Nicolas, dear maintainer(s) of redshift in Debian,
On Do 07 Jan 2021 22:03:11 CET, Debian Bug Tracking System wrote:
Package: redshift-gtk
Version: 1.12-4
Followup-For: Bug #892275
Dear Maintainer,
It seems that I have the same bug since today's reboot.
See the attached screenshot.
Moreover, I can't stop redshift. I close the window and it comes back.
I can't stop it, even killing it makes the fatal window come back again.
redshift uses 100% of a processor.
Yours,
n.
I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to
2.5.7-2, gtk-redshift is broken (again).
For some days now, redshift is unusable, thus bumping severity to
grave again. Also, the upstream activity of redshift is suboptimal.
Many open PRs, last activity dates back to summer 2020. :-(
@Nicolas: with this bash one liner you can kill the redshift process,
if it stubbornly relaunches all the time:
user@host#:~ kill -9 `ps aux | grep redshift | grep -v grep | awk '{
print $2 }'`
Greets,
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net
pgpDQBrk098yw.pgp
Description: Digitale PGP-Signatur
Bug#892275: redshift: Unable to connect to GeoClue.
Package: redshift-gtk Version: 1.12-4 Followup-For: Bug #892275 Dear Maintainer, It seems that I have the same bug since today’s reboot. See the attached screenshot. Moreover, I can’t stop redshift. I close the window and it comes back. I can’t stop it, even killing it makes the fatal window come back again. redshift uses 100% of a processor. Yours, n. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages redshift-gtk depends on: ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii init-system-helpers 1.60 ii python3 3.9.1-1 ii python3-gi 3.38.0-1+b2 ii python3-xdg 0.26-3 ii redshift 1.12-4 Versions of packages redshift-gtk recommends: ii at-spi2-core 2.38.0-2 redshift-gtk suggests no packages. -- no debconf information
Bug#892275: redshift: Unable to connect to GeoClue.
On Mon, 02 Jul 2018 14:23:31 +0530 Ritesh Raj Sarraf wrote: > On Sat, 2018-06-23 at 22:26 +, byanbyanroryan wrote: > > ryan@pocketwee:~$ systemctl --user status redshift > > ● redshift.service - Redshift display colour temperature adjustment > >Loaded: loaded (/usr/lib/systemd/user/redshift.service; disabled; > > vendor preset: enabled) > >Active: inactive (dead) > > Docs: http://jonls.dk/redshift/ > > > Please enable it. That should solve the problem. I have enabled the service and started it via: systemctl --user enable redshift systemctl --user start redshift However, redshift-gtk still refuses to start. :-( Will downgrade geoclue-2.0 as per other suggestion... peace & happiness, martin
Bug#892275: redshift: Unable to connect to GeoClue.
A kind-of ugly hack, until things get sorted out between redshift and geoclue... I have downloaded the debs for my arch (amd64): geoclue-2.0_2.4.7-1_amd64.deb libgeoclue-2-0_2.4.7-1_amd64.deb As root: # dpkg -i libgeoclue-2-0_2.4.7-1_amd64.deb geoclue-2.0_2.4.7-1_amd64.deb # aptitude hold libgeoclue-2-0_2.4.7-1_amd64.deb \ geoclue-2.0_2.4.7-1_amd64.deb This in-effect downgrades geoclue to the last version that worked nicely redshift. All is good in the world! Will revisit this in the future. -- Jerad Simpson
Bug#892275: redshift: Unable to connect to GeoClue.
On Sat, 2018-06-23 at 22:26 +, byanbyanroryan wrote: > ryan@pocketwee:~$ systemctl --user status redshift > ● redshift.service - Redshift display colour temperature adjustment >Loaded: loaded (/usr/lib/systemd/user/redshift.service; disabled; > vendor preset: enabled) >Active: inactive (dead) > Docs: http://jonls.dk/redshift/ Please enable it. That should solve the problem. > On Friday, June 22, 2018, 3:12:41 AM EDT, Ritesh Raj Sarraf > wrote: > > > On Sun, 2018-06-17 at 20:59 -0400, ryan wrote: > > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'redshift' > > disallowed, no > > agent for UID 1000. > > Did you enable the systemd unit ? > > What is the output from the below command ? > systemctl --user status redshift > > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#892275: redshift: Unable to connect to GeoClue.
ryan@pocketwee:~$ systemctl --user status redshift ● redshift.service - Redshift display colour temperature adjustment Loaded: loaded (/usr/lib/systemd/user/redshift.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: http://jonls.dk/redshift/ On Friday, June 22, 2018, 3:12:41 AM EDT, Ritesh Raj Sarraf wrote: On Sun, 2018-06-17 at 20:59 -0400, ryan wrote: > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'redshift' > disallowed, no > agent for UID 1000. Did you enable the systemd unit ? What is the output from the below command ? systemctl --user status redshift -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
Bug#892275: redshift: Unable to connect to GeoClue.
On Sun, 2018-06-17 at 20:59 -0400, ryan wrote: > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'redshift' > disallowed, no > agent for UID 1000. Did you enable the systemd unit ? What is the output from the below command ? systemctl --user status redshift -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
