pam_passwdqc update to latest vendor release
Hello, I read a mail on this list 3 or 4 weeks saying/stating that pam_passwdqc was out of date. To update the module I used the vendor release 1.0.5 which can be found here http://www.openwall.com/pam/modules/pam_passwdqc/pam_passwdqc-1.0.5.tar.gz The patch is available here: http://bifteki.podzone.org/~ltsampros/pam_passwdc.diff And a summary of the patch: M contrib/pam_modules/pam_passwdqc/INTERNALS M contrib/pam_modules/pam_passwdqc/LICENSE M contrib/pam_modules/pam_passwdqc/Makefile M contrib/pam_modules/pam_passwdqc/PLATFORMS M contrib/pam_modules/pam_passwdqc/README M contrib/pam_modules/pam_passwdqc/pam_macros.h M contrib/pam_modules/pam_passwdqc/pam_passwdqc.c A contrib/pam_modules/pam_passwdqc/pam_passwdqc.map M contrib/pam_modules/pam_passwdqc/pam_passwdqc.spec M contrib/pam_modules/pam_passwdqc/passwdqc.h M contrib/pam_modules/pam_passwdqc/passwdqc_check.c M contrib/pam_modules/pam_passwdqc/passwdqc_random.c M lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 I built the updated module on my system. I did some testing with the default options in /etc/pam.d/passwd and it seems to work okey. Feedback is welcome. Regards Leonidas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Passenger hangs on live and SEGV on tests possible threading / kernel bug?
We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: > We're having an issue with Passenger on FreeBSD where it will hang > and stop processing any more requests the details are attach to > the following bug report: > http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 > > In addition the test suite crashes in what seems to be a very > basic test, which I'm at a loss with. > http://code.google.com/p/phusion-passenger/issues/detail?id=441 > > I'm thinking this may be a bugs in the FreeBSD either kernel or > thread library as the crashes don't make any sense from the > application side. > > Any advise on debugging or feedback on the stack traces would > be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? For example: # cd /usr/src/lib/libc # make clean # make DEBUG_FLAGS=-g # make DEBUG_FLAGS=-g install However, if you are hanging in read(), that usually means you have a socket that just doesn't have data. That might be an application bug of some sort. The segv trace doesn't include the first part of GDB messages which show which thread actually had a seg fault. It looks like it was the thread that was throwing an exception. However, nanosleep() doesn't throw exceptions, so that stack trace doesn't really make sense either. Perhaps that stack is hosed by the exception handling code? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
On Thu, 17 Dec 2009, John Baldwin wrote: On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? Yes, good advice, I have noticed that you can't trust GDB stack traces unless libc and libthr have been built with debug (-g) enabled. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
- Original Message - From: "John Baldwin" For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? For example: # cd /usr/src/lib/libc # make clean # make DEBUG_FLAGS=-g # make DEBUG_FLAGS=-g install However, if you are hanging in read(), that usually means you have a socket that just doesn't have data. That might be an application bug of some sort. The segv trace doesn't include the first part of GDB messages which show which thread actually had a seg fault. It looks like it was the thread that was throwing an exception. However, nanosleep() doesn't throw exceptions, so that stack trace doesn't really make sense either. Perhaps that stack is hosed by the exception handling code? I've uploaded a two more traces for the oxt test failure / segv. http://code.google.com/p/phusion-passenger/issues/detail?id=441#c1 From looking at the test case it testing the capture of failures and its ability to create a stack trace output so that may give others some indication where the issue may be? I will look to do the same on for the hang issue but that's on a live site so will need to schedule some downtime before I can get those rebuilt and then wait for it to hang again, which could be quite some time :( Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 8.0-RELEASE-p1 Panic "panic: sbdrop"
On Wed, Dec 16, 2009 at 6:52 AM, Robert Watson wrote: > Could you tell us a bit more about the network configuration -- especially, > are you using any tunneling software (such as ipsec), netgraph, or other > less commonly used network features? Are you using accept filters? Let's see, we are using a couple of simple PF rdr rules in conjunction with squid and yes, we are using accf_http with it as well. Other than that, nothing uncommon. The ethernet is Intel onboard, em0 and em1. Web traffic comes in on em0, gets redirected to squid, and origin server requests go out on e1. It crashed under relatively light traffic, about 3000 requests per minute. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pam_passwdqc update to latest vendor release
On Thu, Dec 17, 2009 at 11:15:30AM +0200, Leonidas Tsampros wrote: > Hello, > > I read a mail on this list 3 or 4 weeks saying/stating that pam_passwdqc > was out of date. To update the module I used the vendor release 1.0.5 > which can be found here > > http://www.openwall.com/pam/modules/pam_passwdqc/pam_passwdqc-1.0.5.tar.gz > > The patch is available here: > > http://bifteki.podzone.org/~ltsampros/pam_passwdc.diff > > And a summary of the patch: > > M contrib/pam_modules/pam_passwdqc/INTERNALS > M contrib/pam_modules/pam_passwdqc/LICENSE > M contrib/pam_modules/pam_passwdqc/Makefile > M contrib/pam_modules/pam_passwdqc/PLATFORMS > M contrib/pam_modules/pam_passwdqc/README > M contrib/pam_modules/pam_passwdqc/pam_macros.h > M contrib/pam_modules/pam_passwdqc/pam_passwdqc.c > A contrib/pam_modules/pam_passwdqc/pam_passwdqc.map > M contrib/pam_modules/pam_passwdqc/pam_passwdqc.spec > M contrib/pam_modules/pam_passwdqc/passwdqc.h > M contrib/pam_modules/pam_passwdqc/passwdqc_check.c > M contrib/pam_modules/pam_passwdqc/passwdqc_random.c > M lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 > > I built the updated module on my system. I did some testing with the > default options in /etc/pam.d/passwd and it seems to work okey. > > Feedback is welcome. Thanks for updating pam_passwdqc. I couldn't find the time to update it myself. It works for me, though the patch doesn't apply cleanly: Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 b/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 |index 408f77d..8247652 100644 |--- a/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 |+++ b/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 -- Patching file lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 using Plan A... Hunk #1 succeeded at 1. Hunk #2 failed at 32. Hunk #3 succeeded at 53. Hunk #4 succeeded at 67. Hunk #5 succeeded at 80. Hunk #6 succeeded at 98. Hunk #7 succeeded at 128. Hunk #8 succeeded at 144. Hunk #9 succeeded at 173. Hunk #10 succeeded at 191. Hunk #11 succeeded at 233. Hunk #12 succeeded at 257. 1 out of 12 hunks failed--saving rejects to lib/libpam/modules/pam_passwdqc/pam_passwdqc.8.rej done Could someone commit this, please? Lars pgpGPSr9xRWs9.pgp Description: PGP signature
Re: pam_passwdqc update to latest vendor release
Lars Engels writes: > On Thu, Dec 17, 2009 at 11:15:30AM +0200, Leonidas Tsampros wrote: >> Hello, >> >> I read a mail on this list 3 or 4 weeks saying/stating that pam_passwdqc >> was out of date. To update the module I used the vendor release 1.0.5 >> which can be found here >> >> http://www.openwall.com/pam/modules/pam_passwdqc/pam_passwdqc-1.0.5.tar.gz >> >> The patch is available here: >> >> http://bifteki.podzone.org/~ltsampros/pam_passwdc.diff >> >> And a summary of the patch: >> >> M contrib/pam_modules/pam_passwdqc/INTERNALS >> M contrib/pam_modules/pam_passwdqc/LICENSE >> M contrib/pam_modules/pam_passwdqc/Makefile >> M contrib/pam_modules/pam_passwdqc/PLATFORMS >> M contrib/pam_modules/pam_passwdqc/README >> M contrib/pam_modules/pam_passwdqc/pam_macros.h >> M contrib/pam_modules/pam_passwdqc/pam_passwdqc.c >> A contrib/pam_modules/pam_passwdqc/pam_passwdqc.map >> M contrib/pam_modules/pam_passwdqc/pam_passwdqc.spec >> M contrib/pam_modules/pam_passwdqc/passwdqc.h >> M contrib/pam_modules/pam_passwdqc/passwdqc_check.c >> M contrib/pam_modules/pam_passwdqc/passwdqc_random.c >> M lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 >> >> I built the updated module on my system. I did some testing with the >> default options in /etc/pam.d/passwd and it seems to work okey. >> >> Feedback is welcome. > > > Thanks for updating pam_passwdqc. I couldn't find the time to update it > myself. > > It works for me, though the patch doesn't apply cleanly: > > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -- > |diff --git a/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 > b/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 > |index 408f77d..8247652 100644 > |--- a/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 > |+++ b/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 > -- > Patching file lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 using Plan A... > Hunk #1 succeeded at 1. > Hunk #2 failed at 32. > Hunk #3 succeeded at 53. > Hunk #4 succeeded at 67. > Hunk #5 succeeded at 80. > Hunk #6 succeeded at 98. > Hunk #7 succeeded at 128. > Hunk #8 succeeded at 144. > Hunk #9 succeeded at 173. > Hunk #10 succeeded at 191. > Hunk #11 succeeded at 233. > Hunk #12 succeeded at 257. > 1 out of 12 hunks failed--saving rejects to > lib/libpam/modules/pam_passwdqc/pam_passwdqc.8.rej > done > You are right! I did my testing using a local clone from git://gitorious.org/freebsd/freebsd.git and the patch applied cleanly there. I broke up the patch in two files. You can find them here: http://bifteki.podzone.org/~ltsampros/pam_passwdqc.8.diff This is the patch for the man page under lib/libpam/modules/pam_passwdqc. It should apply cleanly now. http://bifteki.podzone.org/~ltsampros/pam_passwdqc.diff This is the patch for the module itself under contrib/pam_modules/pam_passwdqc. It should apply cleanly too using patch -p1. > > Could someone commit this, please? > > > Lars ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
