cooperative-computing-lab/cctools — pull request #115 by batrick (2013-06-29 04:35:20+00:00)
Title: Put parrot in its own process group...

For #44, parrot was in the same process group as the bash script. This caused calls to tcsetpgrp to silently fail:

write(4, "2013/06/28 23:57:00.41 [7291] parrot_run: local: ioctl 7 0x5403 0x9c202fc0\n", 75) = 75
ioctl(7, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {c_iflags=0x4400, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a31, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0, c_cc="\x03\x1c\x08\x15\x04\x00\x01\x00\x00\x00\x1a\x00\x12\x0f\x17\x00\x00\x00\x00"}) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTTOU {si_signo=SIGTTOU, si_code=SI_KERNEL, si_value={int=5, ptr=0x5}} ---
ioctl(1, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [7290]) = 0
ioctl(2, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [7290]) = 0
rt_sigreturn() = -1 EINTR (Interrupted system call)

Unfortunately I think the tcsetpgrp in the SIGTTOU signal handler was not failing with EINVAL because Linux doesn't expect you to give a process group that doesn't exist? In this case, Parrot was giving its own process ID instead of the process group. I have corrected this.

Parrot should also be in its own process group since it is fiddling with the terminals in such ... brute-force ... ways. In particular, stealing control of terminals from children. :) We want any signals associated with Parrot's bad behavior to only be sent to Parrot. So, put Parrot in its own process group too.

Fixes #44.