9.1-STABLE, live lock up, seems that it is ZFS lockup in "zfskern{txg_thread_enter}" state "tx->tx"
Hello, freebsd-fs.
I have 9.1-STABLE (r244958) system, amd64, 8GiB memory.
Two SATA disks, 750Gb each.
Disks are partitoned into 7 (BSD) partitons (exactly the same), 5 of
these pairs are joined into gmirrors for "system" FSes (UFS2), one
pair is used for swaps and 7th pair is used as zmirror for /usr/home.
Tonight system becomes unusable, as every process which try to read
directories in /usr/home (like "ls ~" or "find /usr/home -type f")
hangs forever. I could login to system, login shell starts, but if I
run "ls" right after -- it hangs. Every periodic process, which try
to read home FS (directories, not files!) hangs. It looks, like
stat() calls on this FS hangs, but not open()/read()/write()/close().
One thing I fins suspicious in different system diagnostics, is
kernel thread "zfskern{txg_thread_enter}" which is shown in state
"tx->tx" forever.
Disks looks completely OK according to smartd/smartctl, no hardware
errors in dmesg, etc.
===
# zpool status
pool: pool
state: ONLINE
status: The pool is formatted using a legacy on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on software that does not support
feature
flags.
scan: resilvered 32.1G in 0h34m with 0 errors on Sat Jun 2 16:22:59 2012
config:
NAME STATE READ WRITE CKSUM
pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0s1h ONLINE 0 0 0
ada1s1h ONLINE 0 0 0
errors: No known data errors
--
// Black Lion AKA Lev Serebryakov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: About kern.ipc.somaxconn and netstat
On 31/01/2013 4:54 AM, Efraín Déctor wrote: > -Mensaje original- From: Kubilay Kocak > Sent: Wednesday, January 30, 2013 3:25 AM > To: Efraín Déctor > Cc: freebsd-stable@freebsd.org > Subject: Re: About kern.ipc.somaxconn and netstat > > On 30/01/2013 12:26 PM, Efraín Déctor wrote: >> Hello. >> >> We have a webserver using FreeBSD, we read about tunning >> kern.ipc.somaxconn >> (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) >> so the OS can handle all the connections. Is there a way to know how >> many connections are established in a certain moment?. I know about >> netstat(1) but is there any other command that we can use to know the >> exact amount of how many connections are established?. >> > This one might help: > > kern.ipc.numopensockets: Number of open sockets > > It's usefulness will depend on the granularity you require (in only, out > only, established only, etc) but it's always represented system-wide > resource consumption very well (matching observed workloads - baseline value>) > > > Thank you, it is very helpfull, using kern.ipc.numopensockets with > sockstat(1) and netstat(1) will give me a clue to tune kern.ipc.somaxconn > > Thank you all. Also, if you haven't already come across this one in your netstat travels, this one directly reports listen queue overflows: netstat -s -p tcp |grep listen -- Ta, Koobs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9
On Thu, Jan 17, 2013 at 09:15:02AM -0600, Brooks Davis wrote: > Not unless you consider adding new functions in a reserved namespace > (str*) to be ABI breakage. Well, what often happens is that when we add new functions, ports break. I think deciding whether this is or is not "ABI breakage" is semantics. The fact is that regressions get introduced with these types of changes. > The port should have continued to work unless it was recompiled so it > should have preferred it's own version of the strnvis symbol. If its > makefiles were properly constructed it would have failed to compile > due to the signature mismatch. The mantra should be "every possible combination of ways that a port's internal build glue can be wrong, is already included in the Ports Collection." In case after case we see fragile code that is written by people who are clearly not professionally trained. They "get it to work on their system" and then shove it out the door. Claiming that "they shouldn't do that" is correct but self-defeating. It's just the reality of open-source software. IMHO, the burden should be on whoever makes the change to find out whether or not regressions will be introduced. (And yes, I am very aware that we don't have -exp run capability right now, but this is one of the cases where I would like to suggest it would have helped.) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
