Comment 23 for bug 1385641

The workaround works for me (with Dell XPS Developer Edition).

Regarding what's actually happening, it looks like after suspend/resume the input device used by urfkill (in my case, /dev/input/event4) comes back with a different inode number, so that the file descriptor held by urfkill is invalid, as seen in Alex' /proc/<pid>/fd listing above as well. I assume the device driver deletes the file on suspend and recreates it on resume. Restarting urfkill makes it open the file during initialization, and consequently the file descriptor is valid and the issue does not occiur.