buglist.bug

29
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.
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?
22	1	open	Add more information to TS_SAVELIST (from ts -i, for example)	
23	-5	done	"ts -S" could return the number of slots set.	
19	-10	fixed	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
18	2	open	Making a different TS_SAVELIST name on each socket/date	
28	10	open	Security thread on the unix socket	\nFrom http://www.lst.de/~okir/blackhats/node55.html:\n\n\nUnix sockets and named pipes\n\nSimilar problems arise when you want to use Unix domain sockets or named pipes\nin /tmp or other hostile directories.4.4\n\nThe KDE desktop comes with an application called kdesu which is a GUI frontend\nto the su program. In an act of unparalleled user-friendliness it will try to\ncache the password for you. Rather than storing it in a file, the password is\nhanded to a separate daemon process that kdesu talks to via a Unix domain socket\nnamed /tmp/.kdesu_userid. The problem with this was that kdesu didn't care who\nor what had created the socket, and was willing to talk to anyone as long as the\nsocket was there. This made it very easy for an attacker to write a rogue\npassword caching daemon that, as a side effect, would ``cache'' the passwords in\na file owned by the attacker.