Date: Sun, 2 Apr 2006 22:31:39 -0300 (ADT) From: "Marc G. Fournier" <scrappy@postgresql.org> To: Tom Lane <tgl@sss.pgh.pa.us> Cc: "Marc G. Fournier" <scrappy@postgresql.org>, Kris Kennaway <kris@obsecurity.org>, freebsd-stable@freebsd.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <20060402222843.X947@ganymede.hub.org> In-Reply-To: <26524.1144026385@sss.pgh.pa.us> References: <20060402163504.T947@ganymede.hub.org> <25422.1144016604@sss.pgh.pa.us> <25526.1144017388@sss.pgh.pa.us> <20060402213921.V947@ganymede.hub.org> <26524.1144026385@sss.pgh.pa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Apr 2006, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: >> On Sun, 2 Apr 2006, Tom Lane wrote: >>> BTW, even before doing that, you should look at "ipcs -s" output to try >>> to get a clue what's going on. The EINVAL failures may be because the >>> second postmaster to start deletes the semaphores created by the first >>> one. You could easily see this happening in before-and-after ipcs data >>> if so. > >> You are right ... > > OK, could we see strace (or whatever BSD calls it) output for the second > postmaster? I'd like to see exactly what results it's getting for the > kernel calls it makes during IpcSemaphoreCreate. 'k, dont' know what strace is ... we have ktrace and truss ... truss is what I usually use, and is: DESCRIPTION The truss utility traces the system calls called by the specified process or program. Output is to the specified output file, or standard error by default. It does this by stopping and restarting the process being moni- tored via procfs(5). And shows output like: # truss ls ioctl(1,TIOCGETA,0x7fbff514) = 0 (0x0) ioctl(1,TIOCGWINSZ,0x7fbff588) = 0 (0x0) getuid() = 0 (0x0) readlink("/etc/malloc.conf",0x7fbff470,63) ERR#2 'No such file or directory' mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671666176 (0x2808d000) break(0x809b000) = 0 (0x0) break(0x809c000) = 0 (0x0) break(0x809d000) = 0 (0x0) break(0x809e000) = 0 (0x0) stat(".",0x7fbff470) = 0 (0x0) open(".",0x0,00) = 3 (0x3) fchdir(0x3) = 0 (0x0) open(".",0x0,00) = 4 (0x4) stat(".",0x7fbff430) = 0 (0x0) open(".",0x4,00) = 5 (0x5) fstat(5,0x7fbff430) = 0 (0x0) fcntl(0x5,0x2,0x1) = 0 (0x0) __sysctl(0x7fbff2e8,0x2,0x8098760,0x7fbff2e4,0x0,0x0) = 0 (0x0) fstatfs(0x5,0x7fbff330) = 0 (0x0) break(0x809f000) = 0 (0x0) getdirentries(0x5,0x809e000,0x1000,0x809a0b4) = 512 (0x200) getdirentries(0x5,0x809e000,0x1000,0x809a0b4) = 0 (0x0) lseek(5,0x0,0) = 0 (0x0) close(5) = 0 (0x0) fchdir(0x4) = 0 (0x0) close(4) = 0 (0x0) fstat(1,0x7fbff270) = 0 (0x0) break(0x80a0000) = 0 (0x0) ioctl(1,TIOCGETA,0x7fbff2a4) = 0 (0x0) .cshrc .cvspass .history .login .psql_history .ssh write(1,0x809f000,53) = 53 (0x35) .cshrc~ .emacs.d .klogin .profile .rnd ktrace.out write(1,0x809f000,53) = 53 (0x35) exit(0x0) process exit, rval = 0 ktrace is: DESCRIPTION The ktrace utility enables kernel trace logging for the specified pro- cesses. Kernel trace data is logged to the file ktrace.out. The kernel operations that are traced include system calls, namei translations, sig- nal processing, and I/O. And shows output like: 86523 ls RET __sysctl 0 86523 ls CALL fstatfs(0x5,0x7fbff330) 86523 ls RET fstatfs 0 86523 ls CALL break(0x809f000) 86523 ls RET break 0 86523 ls CALL getdirentries(0x5,0x809e000,0x1000,0x809a0b4) 86523 ls RET getdirentries 512/0x200 86523 ls CALL getdirentries(0x5,0x809e000,0x1000,0x809a0b4) 86523 ls RET getdirentries 0 86523 ls CALL lseek(0x5,0,0,0,0) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060402222843.X947>