Bug #78594 for makepp: Extra fork in makepp causes problems

Thu Jul 26 14:01:03 2012 yshtil [...] nvidia.com - Ticket created

Subject:	Extra fork in makepp causes problems
Date:	Thu, 26 Jul 2012 11:00:39 -0700
To:	"bug-makepp [...] rt.cpan.org" <bug-makepp [...] rt.cpan.org>
From:	Yuri Shtil <yshtil [...] nvidia.com>

Hi, I noticed that if the action line of a target starts with -, makepp creates an extra fork layer: makepp -> makepp -> script As opposed to makepp -> script when no dash is present. In the second scenario if a signal INT/TERM is sent to the makepp process, nothing happens (as it should). In the first scenario, if the INT/TERM is sent to the FIRST makepp, nothing happens - OK. If the INT/TERM is sent to the SECOND makepp, it exits immediately leaving an orphan script process. This causes a lot of problems when running under LSF. If a job is killed , it apparently send an INT/TERM to the whole process group, and then after a while if the processes still running, sends KILL. The first INT/TERM leaves orphans for all actions that are with a dash. Attached are Makeppfile and the script to reproduce the problem. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

Download bug.tar.gz
application/x-gzip 440b

Message body not shown because it is not plain text.

Sat Aug 25 06:40:41 2012 occitan [...] esperanto.org - Taken

Sat Aug 25 07:02:01 2012 occitan [...] esperanto.org - Correspondence added

Ok, 1st, the extra process is normal, it is there to intercept the exit code of your action and (as requested by '-') exit(0) instead of whatever came back. The extra process is actually the normal case, only the last action of a rule (which is often the only one) has an optimization of being exec`ed directly (unless you prevent that with '-'). I am not an expert on signal propagation. From the source code I see that the intermediate process resets signal handlers to DEFAULT, so you get the normal system behaviour here. By adding -opgid to ps, I see that the main makepp process is group leader, this may have something to do with the difference you see. OTOH, the main process also does some extra work about signals... I don't know LSF, it sounds kinda scary that someone is overruling mpp's scheduling by randomly sending signals. I only read their overview, it doesn't give a clue about what "Platform Make" really does. Note that mpp has a rule option like ":dispatch lsf-wrapper" which is meant to interface into such systems.

Sat Aug 25 07:02:09 2012 The RT System itself - Status changed from 'new' to 'open'

Sat Dec 29 11:46:29 2012 occitan [...] esperanto.org - Correspondence added

The answer seems to have been enough.

Sat Dec 29 11:46:30 2012 occitan [...] esperanto.org - Status changed from 'open' to 'resolved'