redshift appears to stop working after resume from suspend

[deutrino]

Linux Mint Xfce 17.1, 32-bit, on a Core 2 Duo iMac.

redshift stops adjusting the color of the screen eventually. I believe this occurs after resume from suspend. redshift and gtk-redshift 1.9.1.1-trusty.

[maandree]

Are you refering to suspend–resume on the computer? And what about hibernate? Suspend–resume (both SIGTSTP and SIGSTOP) on the process works as expected on version 1.10.

I have not tested suspending the process for that long. But I will suspend it over the night to see what happens.

[maandree]

I can now comfirm this bug.

[xwhatsit]

Seeing the same thing after suspending overnight. Archlinux using the supplied systemd units to run it automatically as a user service. Method is randr (Intel Sandy Bridge graphics). Attaching strace shows repeated nanosleep calls, and when you stop the process with systemd, it waits around for a bit doing its usual ramp back to 6500K, but the screen still stays at 3500K. When I run it again manually, it instantly snaps to 6500K before ramping down to 5500K. I assume this means it's still running correctly in the background, but perhaps randr has stopped listening?

[maandree]

I think this bug can be fixed by reconnecting to the display when SIGCONT is received.

[caseydentinger]

Experiencing this in Stretch with Redshift 1.10, here's a possible workaround:

/lib/systemd/system/redshift-resume.service

[Unit]
Description=restart redshift because of a bug
After=suspend.target

[Service]
User=casey
Type=oneshot
ExecStart=/usr/local/bin/redshift-resume
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target

/usr/local/bin/redshift-resume

if ! pidof -s redshift > /dev/null; then
        redshift -m randr -l 40:-105 &
fi

[jmgrosen]

I'm having a similar bug, except restarting redshift doesn't help. Even trying to re-set the gamma using xrandr manually doesn't work. Has anyone else seen this / know of a fix?

[MoonSweep]

Bug confirmed on Debian Stretch, Redshift 1.11. I put the computer to sleep through an at job to run pm-suspend as root. The computer slept only for approximately 6 hours.

I still use sysvinit (but I don't think it makes a difference over systemd).

[m1cm1c]

Has this a prospect of getting fixed? Has it already been fixed by someone, just not sent upstream?

[grant-park]

still facing issue, with latest release

[shazow]

If anyone is using a redshift user-level systemd service, here's a somewhat simpler resume service I'm using:

In ~/.config/systemd/user/redshift-resume.service:

[Unit]
Description=Restart redshift on resume
After=suspend.target

[Service]
ExecStart=/usr/bin/systemctl --user restart redshift.service

[Install]
WantedBy=suspend.target

Then run:

$ systemctl --user enable redshift-resume

[m1cm1c]

I'm not experiencing the problem anymore ever since I started explicitly stating my coordinates. So maybe give this a shot.

[wolftune]

I'm having this trouble on KDE Neon (based on Ubuntu 20.04), at least with external monitors. I don't recall the problem with my laptop monitor itself in the past. Maybe that's a hunt. I explicitly stated my coordinates but that didn't solve the issue.

If I toggle redshift off and on, it then engages.

[gustavklopp]

Any workaround or way of debugging this? This problem started for me a few weeks ago (I don't recall exactly when).