--- a/buglist.bug	Mon Nov 03 20:23:35 2008 +0100
+++ b/buglist.bug	Sun Nov 09 12:36:06 2008 +0100
@@ -1,6 +1,12 @@
-18
+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?
+21	10	open	Make a ts error file for each socket	> The error file is (better: was) usless for me. I installed ts\n> via emerge and a error-file was created during install. But it\n> belonges to the user portage. Could you change this filename\n> to allow to have one error file per user?\nI could make one for each socket, yes. I'll write that.\n\n
+22	1	open	Add more information to TS_SAVELIST (from ts -i, for example)	
+23	5	open	"ts -S" could return the number of slots set.