Quoth Nicola Girardi via 9fans <[email protected]>: > Quoth Nicola Girardi via 9fans <[email protected]>: > > The process stuck writing to the seemail port is indeed upas/fs: > > > > 312 fs Pwrite 21a04c 5 > > 0x44c160/"mailfs.seemail./mail/[email protected]" > > 205 -1 > > > > This makes sense, because the process that needs to receive the > > message is Mail, which is itself stuck, here are the last few lines > > from its trace: > > > > 403 Mail Open 21ac1c 0x40e000/"/mail/fs/ctl" 0x1 = 16 "" > > 173579477431 173584571672 > > [... omitted two successful writes to other fids ...] > > 403 Mail Pwrite 20ace8 16 0x472c78/"delete.mbox.9" 13 -1 > > > > which suggests that Mail is waiting for upas/fs to receive the message > > written to the control file, so they're deadlocked; I'll test this > > hypothesis. > > > > For comparison, here's what the trace would look like when Mail does > > not get stuck: > > > > 415 Mail Pwrite 20ace8 16 0x472c78/"delete.mbox.6" 13 -1 = 13 "" > > 163054398681 163274619092 > > 415 Mail Close 21ac3a 16 = 0 "" 163275175643 163275183465 > > > > > The most useful thing you could do would be to capture > > > stacks from all of the Mail procs that are hanging, > > > and send them; see lstk(1) or acid. > > > > Okay, thanks the pointers Ori. I'll send this reply while I have a > > working Mail+upas/fs pair! and will check stack traces later. > > AFAICS the stack traces support that theory. Mbmain() processes both > seemail messages (from upas/fs) and events (from acme). Maybe those > could be different procs? > > acid: lstk() # Mail > pwrite(a0=0x10)+0xe /sys/src/libc/9syscall/pwrite.s:6 > write(buf=0x472c78,n=0x200000000d)+0x27 /sys/src/libc/9sys/write.c:7 > _fmtFdFlush(f=0x472d78)+0x3a /sys/src/libc/fmt/vfprint.c:15 > vfprint(args=0x472e20,fmt=0x405d7a)+0x6f /sys/src/libc/fmt/vfprint.c:31 > fprint(fmt=0x405d7a)+0x22 /sys/src/libc/fmt/fprint.c:13 > mbflush()+0x15a /sys/src/cmd/upas/Mail/mbox.c:733 > doevent(ev=0x40d460)+0x11f /sys/src/cmd/upas/Mail/mbox.c:990 > mbmain(cmd=0x40ee60)+0x1fc /sys/src/cmd/upas/Mail/mbox.c:1039 > launcheramd64(arg=0x40ee60,f=0x20270b)+0x10 /sys/src/libthread/amd64.c:11 > 0xfefefefefefefefe ?file?:0 > > And he's upas/fs sending to the seemail port in the proc that > processes the commands: > > acid: lstk() # upas/fs > pwrite(a0=0x5)+0xe /sys/src/libc/9syscall/pwrite.s:6 > write(buf=0x44a7a0,n=0x7fff000000c4)+0x27 /sys/src/libc/9sys/write.c:7 > myplumbsend(fd=0x5,m=0x7fffffffc7b0)+0x47 /sys/src/cmd/upas/fs/mbox.c:1573 > mailplumb(m=0x455370,mb=0x4387f0)+0x3d4 /sys/src/cmd/upas/fs/mbox.c:1650 > syncmbox(mb=0x4387f0,doplumb=0x1)+0x177 /sys/src/cmd/upas/fs/mbox.c:105 > delmessages(ac=0x2,av=0x7fffffffcb90)+0x115 /sys/src/cmd/upas/fs/mbox.c:1107 > rwrite(f=0x1ad)+0x285 /sys/src/cmd/upas/fs/fs.c:1238 > io()+0x1e9 /sys/src/cmd/upas/fs/fs.c:1436 > main(argc=0x0,argv=0x7fffffffef70)+0x31a /sys/src/cmd/upas/fs/fs.c:353 > _callmain+0x38 /sys/src/libc/9sys/callmain.c:21 >
Interesting. What's the plumber up to? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T92af154d081c9c25-M7ac62968df77959af15c7bcc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
