On Sat, Oct 23, 2010 at 11:15 PM, Graham Dumpleton <[email protected]> wrote: > If possible, next time can you capture it across all process in the > daemon process group. > > Want to validate that whether they are all stuck on flock() or sysvsem > lock in Thread 2. > > This will tell me whether issue is that no process is getting past > lock, or whether one is getting to do apr_poll() on listener socket, > but not seeing a notification.
If this is Linux and you're using file locks, then it may be useful to list the file locks with, cat /proc/locks You may see something like, 1: POSIX ADVISORY WRITE 17188 fd:0c:3145831 0 EOF 1: -> POSIX ADVISORY WRITE 17187 fd:0c:3145831 0 EOF and so on. Lines that have a -> prefix are pending locks (i.e., the process is blocked waiting on the lock), whereas without the arrow prefix means the lock is currently held. The initial text fields explain what type of lock this is. The number after the RW, READ, or WRITE is the process pid. If the lock is on a a file (which will be most cases), then there is a three-number colon-separated field to identify the file: a) the filesystem's device major number in hex (see /proc/devices) b) the filesystem's device minor number, in hex c) the file's inode number The last two fields are the file offset range that the lock covers, but won't be that interesting in this case. -- Deron Meranda http://deron.meranda.us/ -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
