Summary: | mail-filter/opendkim needs optimization | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christian Roessner <c> |
Component: | New packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
opendkim-2.7.4.ebuild
strl patch grabbed from 2.7.2 build git commit 23548465adccd682ba9ecba58025f852d2353bad |
Description
Christian Roessner
2013-01-16 10:51:10 UTC
(In reply to comment #0) > First of all, the dependency for strl is missing (dev-libs/libstrl) Not really. Opendkim has an internal libstrl implementation which is cleaner and is probably faster than libstrl. Opendkim uses the internal implementation when libsrl is not present. Moreover, make check fails when opendkim is linked against libstrl (but passes with internal implementation). This is the main reason I did not bump opendkim yet. I need to find some time and figure out why make check fails when linked against libstrl. > Documentation requires flag --with-milter. I am not sure I understand. I will check when I am at my dev box. > If using ldap, it might be interesting to add --enable-ldap_caching No. It does not do what you think it does. You will have to restart opendkim when ldap data changes with --enable-ldap_caching. > Of course this is dirty hack and options should go somewhere to > /etc/conf.d/opendkim I will have a look. > If you have multiple instances of opendkim, you get segmentation faults when > stopping a service. That looks like a problem with start-stop-daemon not with opendkim. I removed --with-milter, --enable-ldap_caching. Also removed strl package and rebuilt. Here is the init script segfault problem: [83139.618188] opendkim[4687]: segfault at 1f0 ip 000072d6962be394 sp 00007401911a9c60 error 4 in libpthread-2.15.so[72d6962b4000+18000] [83139.618216] grsec: Segmentation fault occurred at 00000000000001f0 in /usr/sbin/opendkim[opendkim:4687] uid/euid:105/105 gid/egid:998/998, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 [83139.618286] grsec: bruteforce prevention initiated against uid 105, banning for 15 minutes (gdb) continue Continuing. [Thread 0x7051a9b60700 (LWP 15401) exited] Program received signal SIGSEGV, Segmentation fault. 0x00007051ace02394 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007051ace02394 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00000e96a32a99e0 in ?? () #2 0x00007051ad157bc7 in CRYPTO_add_lock () from /usr/lib64/libcrypto.so.1.0.0 #3 0x00007051ad40c5c0 in SSL_CTX_free () from /usr/lib64/libssl.so.1.0.0 #4 0x00007051ae09fee6 in ldap_int_tls_destroy () from /usr/lib64/libldap-2.4.so.2 #5 0x00007051af1baa7c in ?? () from /lib64/ld-linux-x86-64.so.2 #6 0x00007051aca855d1 in ?? () from /lib64/libc.so.6 #7 0x00007051aca85625 in exit () from /lib64/libc.so.6 #8 0x00007051aca6f494 in __libc_start_main () from /lib64/libc.so.6 #9 0x00000e96a32940d1 in ?? () #10 0x00007b2529531cf8 in ?? () #11 0x000000000000001c in ?? () #12 0x0000000000000003 in ?? () #13 0x00007b2529531f7d in ?? () #14 0x00007b2529531f90 in ?? () #15 0x00007b2529531f93 in ?? () #16 0x0000000000000000 in ?? () (gdb) stop (gdb) UP TO HERE, grsec is _not_ blocking opendkim. (gdb) quit A debugging session is active. Inferior 1 [process 15399] will be detached. Quit anyway? (y or n) y Detaching from program: /usr/sbin/opendkim, process 15399 NOW opendkim gets blocked (brute force detection) Do you want to contact Murray? I have subscribed opendkim-users and I know Muray personally, so I could figure things out and ask to get things fixed? But I do not want to do this, unless you want to. (In reply to comment #3) > Do you want to contact Murray? I have subscribed opendkim-users and I know > Muray personally, so I could figure things out and ask to get things fixed? Please do contact upstream. It would be a great help. You will need to get a backtrace with debugging symbols though. The following might help: http://www.gentoo.org/proj/en/qa/backtraces.xml Upstream is informed. It is a known bug: https://sourceforge.net/tracker/?func=detail&atid=1147701&aid=3531477&group_id=269812 Murray is soon starting 2.8 betas. I asked to get a back port patch for 2.7.4 His answer: This is a known problem for installations that use openldap with opendkim. openldap goes through some steps to ensure that libcrypto is set up with mutexes as openssl requires, but opendkim does the same set of steps; during shutdown, both of them call the opposite routine to free those resources but that results in a double-free and/or heap corruption, and you get this crash. I contend that openldap shouldn't be doing this; libraries shouldn't be initializing each other, as that's the job of the application. But understanding that openldap is probably not as agile as we are and may disagree, opendkim 2.8.0 includes the option to skip the libcrypto setup steps in order to avoid this problem. I will be starting 2.8.0 betas soon, so you can give this option a try in the near future. Created attachment 335976 [details]
opendkim-2.7.4.ebuild
This build is not perfect, as I used patch and not patch for one patch. I don't know how to get this done correctly.
Created attachment 335978 [details, diff]
strl patch grabbed from 2.7.2 build
Created attachment 335980 [details, diff]
git commit 23548465adccd682ba9ecba58025f852d2353bad
I have removed the RELEASE_NOTES part, as "patch" did not succeed.
By adding "DisableCryptoInit yes" to your configuration, start/stop will no more seg fault, if using openldap. Thanks for your report. +*opendkim-2.7.4 (18 Jan 2013) + + 18 Jan 2013; Eray Aslan <eras@gentoo.org> + +files/opendkim-2.7.4-DisableCryptoInit.patch, + +files/opendkim-2.7.4-bsd.patch, +files/opendkim.init.r3, + +opendkim-2.7.4.ebuild: + Version bump - bug #452324. Start before mta - bug #451114. Use libbsd instead + of internal library - bug #441790. Add option to disable crypto + initialization thanks to Christian Rößner - bug #452470. + |