Re: Trinity ctrl-c'ing itself?

[Dave Jones <davej@redhat.com>]

On Thu, Jun 06, 2013 at 12:30:31PM +1000, Michael Ellerman wrote:
 > Hi folks,
 > 
 > Has anyone else seen trinity appear to control-c itself?
 > 
 > I've seen this a few times now, and I'm _really_ sure I didn't control-c
 > this one manually. It was running overnight in a screen session.
 > 
 > Tail of output is:
 > 
 > [13645] [120] mbind(start=0, len=0, mode=0, nmask=0x1fffb9cf0010, maxnode=0x80000, flags=0x4000) [13655] [182] add_key(_type=0x7fffffff00001001, _description=0x7fffffff00001009, _payload=0x1ffffe2d0000, plen=0, ringid=0x1000000000) = -1 (Bad address)
 > = -1 (Invalid argument)
 > [13655] [183] getrusage(who=0x8010658612110214, ru=0xc000000000000000) [13645] [121] symlink(oldname="/proc/87/task/87/wchan", newn̳̣��o��s̤�.��̭̣̳̼�  ̢̻��̬�̰̦W̮̲�̼̩��i��͡
 > t�̯�h̷̬���̬Ì�̺��e��[13655] [188] readahead(fd=414, offset=1, count=4096) = 196608
 > = -1 (Bad file descriptor)645] [1i�n�̩̹��̹g� ̠̥=0x1ffffe310000) = 13655
 > child 13585 exiting�̠̲̫�fe̤��̱e�̮̠̹̭��l�̲��̠̪i̢�Ì��̯�̩n̸̰g�̱���̬�̦��I̠child 13655 exiting̷�=413, mode=2047) = 0                                          
 > = 0655] [186] setfsgid(gid=0̣�ḥi̼̦�̼v�̩���̩�n̢�̪��̰̠̦t̺�̰i�n�̮̦��g̮�d̴̺child 13639 exiting�͢ep�r�̯���Ì�e̴s̥e̵�̳� nr_segs=976, flags=6) = 2̪44
 > child 13640 exitingnkat(oldname="", newdfd=413, newname="./pro�̹�̼e̦�̪�latency���๹�๹child 13590 exiting �T̫̺̳o̬� ì̬Ì��nv��̻̣̹�o��̠�̤k
 > child 13536 exiting
 > child 13613 exiting
 > [3791] Bailing main loop. Exit reason: ctrl-c

I've seen it in the past, but not since last summer when I merged
commit dbad5389a1d5d413e533a85f914f3eeef03a3ebe

I wonder if there's some other way we're sending signals to child pids that
currently isn't marked AVOID.

	Dave