Hi guys,
>>> Good point. But I really have no idea, why opendkim runs with non
>>> grsec and seg faults _sometimes_ with grsec.
>>
>> grep OPTI .config
>>
>> try disable the two with INLINING
>>
>> just a wild guess
>
> rns root_at_mx /var/tmp/portage/mail-filter/opendkim-2.10.0/work/opendkim-2.10.0 # grep -R "\binline\b" *
> configure:static inline int
> reprrd/reprrd.php:# load graph for inline presentation
> reputation/README: inline PHP.
>
> Do you really think that gcc inlining could cause such a problem?
>
>> do you use genkernel with --oldconfig ?
>
> Yes. I always do oldconfig manually, but also enabled this feature in genkernel.
>
> It’s really weird.
>
> I need to dive into gdb and I also will try to build opendkim with most less dependencies.
>
> Currently it looks like this:
>
> ldd /usr/sbin/opendkim
> linux-vdso.so.1 (0x000060e21e5ba000)
> libopendkim.so.10 => /usr/lib64/libopendkim.so.10 (0x000060e21e17b000)
> libmilter.so.1.0.2 => /usr/lib64/libmilter.so.1.0.2 (0x000060e21df69000)
> libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x000060e21dbda000)
> libopendbx.so.1 => /usr/lib64/libopendbx.so.1 (0x000060e21d9d5000)
> libmemcached.so.11 => /usr/lib64/libmemcached.so.11 (0x000060e21d78c000)
> liblua.so.5 => /usr/lib64/liblua.so.5 (0x000060e21d558000)
> libm.so.6 => /lib64/libm.so.6 (0x000060e21d256000)
> libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x000060e21d004000)
> libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x000060e21cd90000)
> libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x000060e21c97f000)
> liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x000060e21c76e000)
> libunbound.so.2 => /usr/lib64/libunbound.so.2 (0x000060e21c4e3000)
> libvbr.so.2 => /usr/lib64/libvbr.so.2 (0x000060e21c2de000)
> librbl.so.1 => /usr/lib64/librbl.so.1 (0x000060e21c0d9000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x000060e21bec2000)
> libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x000060e21bcb2000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x000060e21ba94000)
> libc.so.6 => /lib64/libc.so.6 (0x000060e21b6e7000)
> libdl.so.2 => /lib64/libdl.so.2 (0x000060e21b4e3000)
> libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x000060e21b1b7000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x000060e21af9f000)
> libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x000060e21ad80000)
> libz.so.1 => /lib64/libz.so.1 (0x000060e21ab68000)
> libevent-2.0.so.5 => /usr/lib64/libevent-2.0.so.5 (0x000060e21a918000)
> /lib64/ld-linux-x86-64.so.2 (0x000060e21e39c000)
>
> ldd /usr/sbin/opendkim | tail -n 25 | head -n 24 | awk '{ print $3; }' | xargs qfile | cut -d " " -f 1 | sort | uniq
> dev-db/opendbx
> dev-lang/lua
> dev-libs/cyrus-sasl
> dev-libs/libbsd
> dev-libs/libevent
> dev-libs/libmemcached
> dev-libs/openssl
> mail-filter/libmilter
> mail-filter/opendkim
> net-dns/unbound
> net-nds/openldap
> sys-devel/gcc
> sys-libs/db
> sys-libs/glibc
> sys-libs/zlib
I finally reduced dependencies. I compiled opendkim with minimum features and added features test after test. Each time I added a feature, I tested more than 500 mails per stage.
First:
lua, opendbx
When I added memcached, I even was unable to start opendkim anymore. While starting one process (opendkim.verify), the other already running process opendkim.sign crashed. Impossible to get it working.
I removed memcached and also added
reputation (for the experimental DKIM reputation code) and unbound
After more than 1.200 mails, the services are still running.
So it is quite clear that the code introduced for memcached support is broken.
Many thanks for following my mails. Hope someone will have a look at the memcached-code and find the problem
Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com
Received on Mon Jan 12 2015 - 10:36:52 PST