Child process redshift is not terminated properly if redshift-gtk receives a signal

[unode]

This looks like a bug in the way redshift-gtk communicates and passes signals to the child process (redshift). Possibly related to #253 and #218.

If a signal other than SIGUSR1 is sent to the parent process (redshift-gtk), the children process (redshift -v) may be left running while the parent exits.

Steps to reproduce:

1) During a night period start "redshift-gtk" and wait enough time to let the screen tone stabilize
2) Monitor all processes called redshift or redshift-gtk
3) Run "pkill -TERM redshift-gtk"
4) The screen remains in night tone and "redshift -v" should still be visible in the process list while redshift-gtk exited cleanly.

If the signal is sent during the tone change (gradient) phase redshift -v will exit but only due to a broken pipe error caused by producing output to a parent that is no longer there.
This can be confirmed by running the same steps above that lead to an orphan redshift -v process and then run:

5) pkill -TERM redshift

This would normally transition to the "normal" state before exiting. However in this case the process dies immediately and leaves the screen in night tone.

If redshift-gtk is modified to run the child process as redshift instead of redshift -v the broken pipe problem is no longer visible and step 5) will perform the transition to "normal" tone.
However this change is not sufficient to solve the initial problem of the orphaned redshift process.

The best solution would be for redshift-gtk to wait for the child process to finish before exiting, much like the Quit menu action does.

[jonls]

Thanks! I wrote some quick code in #268 to fix what I think is the problem. I didn't have time to test it yet but I'll get back to it later. If you have any suggestions on the pull request or if you can test it, please let me know!

[LiSongMWO]

I believe this is still occurring on 1.12.

I autostart redshift in my session using the handy lill' button in the gtk tray icon. And if I log out and in again I get one more redshift process per time I login.

[doronbehar]

I've had the same issue with AwesomeWM, I opened an issue and I've learned that the redshift-gtk process is killed but not every process in the process group of it is killed, at least by default. I'm not sure how exactly it is fixed in the latest master because I've created a workaround with the stable release for my own usage. Anyway, if you are interested in a workaround, you'll need to configure your WM/DE to kill the process group of redshift-gtk and not just it.

[HansCz]

Same issue here, but with Xfce4

[joanbm]

Using pkill X as a quick way to restart the X server also leaves the 'redshift' process spawned by 'redshift-gtk' running. I have tested this on both Arch+i3 and Lubuntu. I'm not sure how exactly the pkill X command causes the 'redshift-gtk' process to exit, though I think there's some way to gracefully catch it...

However instead of #268 it would be even better to have some system that ensures the child process is always killed the parent dies, even on a kill -9 on the parent. Unfortunately from a quick look it doesn't look like there is some (portable) trivial solution to this, e.g. by passing an extra flag when spawning the process.

[tycho-kirchner]

Are there any news on this?

[jonls]

@joanbm Thanks for the summary, I think this is accurate. There's apparently no way to make sure that the child is definitely terminated when the parent is terminates. redshift-gtk should terminate the child if it's sent the TERM signal but if KILL is sent instead for some reason, the child will likely just be orphaned. I wonder if this is what's happening or if there's some other loophole. If anybody has suggestions to improve the current code in redshift-gtk feel free to open a PR.

I think the long-term solution should be something like #54 where there's no longer a need for redshift-gtk and redshift to be parent/child processes.