Ignore sighups after forking into background

[astrand]

xterm -e xclip && xclip -o

would lead to empty output, and not what the user just typed in in the new terminal.

This is because xclip is not sighup-resistant after forking into background. I put a setsid() syscall just after the fork so xclip is no attached to no terminal and therefore gets no signals.

Reported by: dallaylaen

Original Ticket: xclip/patches/2

[astrand]

Original comment by: dallaylaen

[hackerb9]

Do we want xclip to be SIGHUP resistant? Would there be any downsides to this? Will users be surprised if xclip is hanging around after they logout and log back in?

By the way, the following does work:

xterm -e 'nohup xclip -i <<<foobar' && xclip

[mvuets]

I'd like just to chime in and add that I was bitten by the related "feature" as well. I have a shortcut set up in Vim such that it copies/pastes text via writing to/reading from "xclip -selection clipboard" and it mostly worked fine. There was this one weird corner case though: I couldn't exchange text within the same terminal between Vim and Bash when Vim was suspended (CTRL-Z or SIGSTOP).

After many months suffering from this quirk and then eventually spending a long extensive debugging session with my friend, we found out the cause! xclip would stay in the background and hold (host?) the selection until it was overridden. Since it belonged to the same process group/session as Vim, it would be sent SIGSTOP and suspended as well and thus be unable to serve the selection. We both knew the host process was necessary to serve "-selection primary", but none of us suspected it was needed for "-selection clipboard" just as well. The problem has been fixed by wrapping xclip in setsid(1) (on Linux; unfortunately, to my knowledge there is no such easy workaround on, say, OpenBSD).

I was wondering whether calling setsid(2) from xclip itself would be a good idea and I so found this ticket. The original linked ticket already contains the patch that I had in mind. So I just wanted to share my story.

Two small remarks, though: (1) unlike been discussed here, I didn't have issues with SIGHUP myself, but I came down here from the SIGSTOP route; (2) I am not an expert, so I am not aware of potential negative consequences of setsid(2)'ing.