Removing fixed bugs.
--- a/buglist.bug Sun Nov 09 12:36:06 2008 +0100
+++ b/buglist.bug Sun Nov 09 12:37:29 2008 +0100
@@ -1,9 +1,5 @@
24
0 1 sleep recv() may return ECONNRESET \nI don't know why. It happened sometimes, when the client didn't send any\nENDJOB message.\nIt should be investigated.\n\nHypothesis:\n- maybe recv() returns ECONNRESET if the other side process has died but not\n closed()?\n simple tests seem to show that it's not true.
-5 5 fixed Removing a job doesn't kill the ts client \nThe client rests forever.
-4 5 fixed Terminal Control-C to a "ts -nf myprogram" breaks the queue.
-8 1 fixed Removing a job doesn't wake up its "waiters" \nIn a terminal: ts -w 15\nIn another: ts -r 15\n\nThe first terminal doesn't wake up.
-9 2 fixed The "-t" option doesn't die after the application dies. \n-t could have, moreover, the behaviour of -w
18 1 open Making a different TS_SAVELIST name on each socket/date
19 10 open Killing a child ts blocked the queue ts creates the job in a new Process Group. You can send signals\nto the whole Process Group using a negative number for kill, as\nin: "kill -- -`ts -p`" (the first double hyphen is for sending\nthe default TERM signal, and not mixing the ID with a signal\nnumber).\n\nI finally tried this and it works. Once I accidently killed the\ncorresponding ts process instead and this hung the whole queue:\n\nts(3427)---grandpa(3428)-+-father(3429)-+-son(3430)---sleep(3431)\n | `-son(3435)---sleep(3436)\n `-father(3432)-+-son(3433)---sleep(3434)\n `-son(3437)---sleep(3438)\n\n$ kill -- -3427 #should have been 3428\n$ ts\n\nID State Output E-Level Times(r/u/s) Command [run=1/1]\n1 queued (file) grandpa\n2 queued (file) grandpa\n\nKilling the correct pid 3428 didn't help ts to recover. A 'ts -C'\ndid exactly nothing. Finally 'ts -K' allowed to use ts again.\n\nJust as a note\nThomas
20 1 open Log the output of TS_ONFINISH, for the case it gives an error I actually used this for debugging:\n\nexec >> $HOME/${0##*/}.out 2>&1\ndate; echo params: "$@"; echo\nset -xv\n\nand found that the script is run, but that the server worked\ndifferently from what I expected: My script checks the output\nof ts to be sure that it is run via ts and not via cmdline.\n\nAs the script gets some information as parameters, I checked\nwhether these are in the output of ts. What I expected was\nthat ts would show a line like\n\n0 finished /tmp/ts-out.l8jhbI 0 10.05/0.00/0.00 sleep 10\n\nNow I understand that the (just finished) job is shown as\n\n0 running /tmp/ts-out.l8jhbI sleep 10\n\nin this very moment. I adapted my script and now it works. :-)\n\nBTW: Why don't you just log stdout/stderr of $TS_ONFINISH?