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
--
To unsubscribe from this list: send the line "unsubscribe trinity" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
