There is another problem here: the DROP/RENAME table used by --alter-foreign-keys-method=drop-swap is not atomic, and thus it can be interrupted (which is different from failing as reported here originally).


Output shows "the tool was interrupted":

Child tables:
`EXAMPLEDB`.`STATUS_ITEM` (approx. 140890126 rows)
Will use the drop_swap method to update foreign keys.
Altering `EXAMPLEDB`.`JOB_ITEM`...
Creating new table...
Created new table EXAMPLEDB._JOB_ITEM_new OK.
Altering new table...
Altered `EXAMPLEDB`.`_JOB_ITEM_new` OK.
2015-02-04T18:52:44 Creating triggers...
2015-02-04T18:52:44 Created triggers OK.
2015-02-04T18:52:44 Copying approximately 127945887 rows...
2015-02-04T20:29:41 Copied rows OK.
2015-02-04T20:29:41 Drop-swapping tables...
Not dropping triggers because the tool was interrupted. To drop the triggers, execute:
DROP TRIGGER IF EXISTS `EXAMPLEDB`.`pt_osc_EXAMPLEDB_JOB_ITEM_del`;
DROP TRIGGER IF EXISTS `EXAMPLEDB`.`pt_osc_EXAMPLEDB_JOB_ITEM_upd`;
DROP TRIGGER IF EXISTS `EXAMPLEDB`.`pt_osc_EXAMPLEDB_JOB_ITEM_ins`;
Not dropping the new table `EXAMPLEDB`.`_JOB_ITEM_new` because the tool was interrupted. To drop the new table, execute:
DROP TABLE IF EXISTS `EXAMPLEDB`.`_JOB_ITEM_new`;
Altered `EXAMPLEDB`.`JOB_ITEM` but there were errors or warnings.


And this was run through nohup pt-osc-scripted.sh and the nohup.out file contained:

Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 04:19 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 04:12 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 04:03 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 03:51 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 03:41 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 95% 03:32 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 96% 03:21 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 96% 03:10 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 96% 02:58 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 96% 02:49 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 96% 02:39 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 97% 02:27 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 97% 02:16 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 97% 02:06 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 97% 01:56 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 98% 01:44 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 98% 01:33 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 98% 01:24 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 98% 01:13 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 98% 01:02 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:52 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:44 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:34 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:22 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:11 remain
Copying `EXAMPLEDB`.`JOB_ITEM`: 99% 00:03 remain
# Exiting on SIGHUP.


So, the SIGHUP certainly arrived at a horrible time, and pt-osc acted on it even when the script was run through "nohup" because it reconnects PERL's "normal-signals" (These are the signals w and leave a table and a non-renamed hich a program might normally expect to encounter and which by default cause it to terminate. They are HUP, INT, PIPE and TERM.  http://perldoc.perl.org/sigtrap.html)

What should be done here is make the operation "atomic" in the sense that it can not be interrupted (if the RENAME TABLE fails then it can't be atomic because we can't rollback the DROP TABLE).

So the suggested fix is: wrap the drop_swap handling code with alternative signal handler which will refuse to exit at the critical time between drop and rename.

And for scripters out there: use "disown" instead of "nohup" to avoid most signals getting there.