xflux gets stuck in a loop when stdin is /dev/null

[gfxmonk]

I set up a systemd user service for xflux, which (by default) will attach stdin to /dev/null, because most daemons never touch stdin.

xflux ran without errors, but never actually changed colours - doing an strace revealed that it was reading from stdin in a loop. I can't find any information about what xflux does with stdin, but piping /dev/urandom into it started changing screen colours fairly wildly - so I'm assuming it's a feature to alter configuration while xflux is running, rather than having to restart with new command line flags.

Anyway, it would be great if xflux could detect EOF and stop trying to read from stdin, because this was pretty hard to track down, and the workaround is pretty obtuse (I got systemd to also create a unix socket connected to stdin, and just never connect anything to the other end).

[herf]

Yes this is for our GUI, but it should probably be turned off after fork - good bug.
We're doing a nonblocking select() on stdin, which normally doesn't block.

We will likely do a domain socket instead of this broken stdin command stream as soon as we get someone to fix up the python gui.

Basically all of our bugs on Linux are due to the stdin parser, so I will be glad to be rid of it!

[gfxmonk]

Thanks, good to hear!

Although just to note, you say "it should probably be turned off after fork". For my systemd service, I'm also using -nofork, because having daemons fork themselves is usually unnecessary with systemd, and it's simpler if they don't try. So hopefully the fix can work even in foreground-mode.