abrtd: Package ‘sphinx’ isn’t signed with proper key

Sphinx Search Engine məhşur axtarış motorudur. Database-ə gedən axtarış sorğularını Sphinx-ə yönləndirməklə siz Database-ə düşəcək bu əlavə yükü aradan qaldırmış olursuz.
Bu və digər istifadə yerlərinə görə, Sphinx production səviyyədə geniş tətbiq olunan bir məhsuldur.
Sphinx haqqında rəsmi səhifə Sphinx Search
Mövzumuz Crash zamanı ABRT ilə core dump almaq haqqındadır.
Sphinx 2.1.8 (Sphinx 2.1.8-id64-release (rel21-r4675)) versiyada, DMESG output-dan aldığım məlumatda, Segmentation Fault olduğu görünür. Çox güman ki, BUG-a rast gəlmişəm.
DMESG output:

searchd[63657]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[63902]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[63932]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[63941]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[63986]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[64000]: segfault at 7ffb80168000 ip 00000000004c790d sp 00007fffdc699460 error 4 in searchd[400000+40b000]
searchd[3312]: segfault at 7f5e89892000 ip 00000000004c790d sp 00007fffff4b2660 error 4 in searchd[400000+40b000]
searchd[3406]: segfault at 7f5e89892000 ip 00000000004c790d sp 00007fffff4b2660 error 4 in searchd[400000+40b000]
searchd[3484]: segfault at 7f5e89892000 ip 00000000004c790d sp 00007fffff4b2660 error 4 in searchd[400000+40b000]
searchd[16809]: segfault at 7fb0e063b000 ip 00000000004c790d sp 00007fff1129d270 error 4 in searchd[400000+40b000]

Sphinx log faylından da bunu başa düşmək olur:

------- FATAL: CRASH DUMP -------
[Mon Dec  8 16:34:49.031 2014] [11771]

--- crashed SphinxAPI request dump ---
# 
--- request dump end ---
Sphinx 2.1.8-id64-release (rel21-r4675)
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with gcc 4.4.4
Configured with flags:  '--host=x86_64-unknown-linux-gnu' '--build=x86_64-unknown-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/sphinx' '--with-mysql' '--with-re2' '--with-libstemmer' '--with-unixodbc' '--with-iconv' '--enable-id64' '--with-pgsql' '--with-syslog' 'build_alias=x86_64-unknown-linux-gnu' 'host_alias=x86_64-unknown-linux-gnu' 'CFLAGS=-O2 -g' 'CXXFLAGS=-O2 -g'
Host OS is Linux rhel6064 2.6.32-71.40.1.el6.x86_64 #1 SMP Tue Jul 3 14:39:16 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f5d1aadcdbf, thread stack size = 0x10000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x7f5d1aadcdbf)
Stack looks OK, attempting backtrace.
0x0
Something wrong in frame pointers, manual backtrace failed (fp=0)
Trying system backtrace:
begin of system symbols:
/usr/bin/searchd(_Z12sphBacktraceib+0x9c)[0x619ccc]
/usr/bin/searchd(_ZN16SphCrashLogger_c11HandleCrashEi+0x1b4)[0x4c3b54]
/lib64/libpthread.so.0[0x3d65e0f710]
/usr/bin/searchd(_Z14sphUnzipOffsetRPKh+0x7)[0x526eb7]
/usr/bin/searchd(_ZNK9CWordlist7GetWordEPKhmR13CSphDictEntry+0x38)[0x5289d8]
/usr/bin/searchd(_ZNK21DiskIndexQwordSetup_c5SetupI16DiskIndexQword_cILb1ELb0ELb0EEEEbP9ISphQword+0x46e)[0x5a363e]
/usr/bin/searchd[0x6d3ea3]
/usr/bin/searchd(_ZN9ExtNode_i6CreateERK11XQKeyword_tPK8XQNode_tRK14ISphQwordSetup+0x1e)[0x6d48ee]
/usr/bin/searchd(_ZN9ExtNode_i6CreateEPK8XQNode_tRK14ISphQwordSetup+0xb2)[0x6d5172]
/usr/bin/searchd(_ZN11ExtRanker_cC1ERK9XQQuery_tRK14ISphQwordSetup+0x326)[0x6d6576]
/usr/bin/searchd(_Z15sphCreateRankerRK9XQQuery_tPK9CSphQueryP15CSphQueryResultRK14ISphQwordSetupRK16CSphQueryContext+0xa04)[0x6d7a74]
/usr/bin/searchd(_ZNK13CSphIndex_VLN16ParsedMultiQueryEPK9CSphQueryP15CSphQueryResultiPP15ISphMatchSorterRK9XQQuery_tP8CSphDictPK10CSphVectorI18CSphFilterSettings16CSphVectorPolicyISE_EEP18CSphQueryNodeCacheib+0x628)[0x55ef18]
/usr/bin/searchd(_ZNK13CSphIndex_VLN10MultiQueryEPK9CSphQueryP15CSphQueryResultiPP15ISphMatchSorterPK10CSphVectorI18CSphFilterSettings16CSphVectorPolicyIS9_EEib+0x674)[0x576874]
/usr/bin/searchd(_ZNK13CSphIndex_VLN12MultiQueryExEiPK9CSphQueryPP15CSphQueryResultPP15ISphMatchSorterPK10CSphVectorI18CSphFilterSettings16CSphVectorPolicyISA_EEib+0x76d)[0x57718d]
/usr/bin/searchd(_ZN15SearchHandler_c16RunLocalSearchesEP15ISphMatchSorterPKcb+0xfc1)[0x4f55e1]
/usr/bin/searchd(_ZN15SearchHandler_c9RunSubsetEii+0x2722)[0x4f81f2]
/usr/bin/searchd(_ZN15SearchHandler_c10RunQueriesEv+0x1e)[0x50005e]
/usr/bin/searchd(_Z19HandleCommandSearchiiR13InputBuffer_c+0x1b8)[0x503d88]
/usr/bin/searchd(_Z18HandleClientSphinxiPKcP9ThdDesc_t+0x51a)[0x50c2fa]
/usr/bin/searchd(_Z13HandlerThreadPv+0x57)[0x50c4b7]
/usr/bin/searchd(_Z20sphThreadProcWrapperPv+0x19)[0x622cd9]
/lib64/libpthread.so.0[0x3d65e079d1]
/lib64/libc.so.6(clone+0x6d)[0x3d65ae89dd]
-------------- backtrace ends here ---------------
Backtrace looks OK. Now you have to do following steps:
  1. Run the command over the crashed binary (for example, 'searchd'):
     nm -n searchd > searchd.sym
  2. Attach the binary, generated .sym and the text of backtrace (see above) to the bug report.
Also you can read the section about resolving backtraces in the documentation.
--- BT to source lines (depth 23): ---
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
--- BT to source lines finished ---
--- 1 active threads ---
thd 0, proto sphinxapi, state query, command search
------- CRASH DUMP END -------

Bildiyimiz kimi, Red Hat based linux-larda (indiki halda CentOS 6) default crash toplayıcısı ABRT-dir. default ABRT path, /var/spool/abrt/-dir.
Yəni hər hansı ciddi crash zamanı, crash edən paketin core dump-ı əlavə araşdırmalar məqsədilə verilmiş path-də saxlanılır.
Bu path-ə nəzər yetirdikdə orada heç bir core dump-ın olmadığını görürük.

root# ls /var/spool/abrt/
abrt-db  last-ccpp

Səbəbini isə /var/log/messages faylından tapırıq:

kernel: searchd[11746]: segfault at 7f5d24087000 ip 00000000004c790d sp 00007fff87535c50 error 4 in searchd[400000+40b000]
Dec  8 16:32:57  abrtd: Directory 'ccpp-2014-12-08-16:32:57-11746' creation detected
Dec  8 16:32:57  abrt[11757]: Saved core dump of pid 11746 (/usr/bin/searchd) to /var/spool/abrt/ccpp-2014-12-08-16:32:57-11746 (158187520 bytes)
Dec  8 16:32:57  abrtd: Package 'sphinx' isn't signed with proper key
Dec  8 16:32:57  abrtd: 'post-create' on '/var/spool/abrt/ccpp-2014-12-08-16:32:57-11746' exited with 1 
Dec  8 16:32:57  abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2014-12-08-16:32:57-11746'

Log fayldan gördüyümüzə əsasən, deyirik ki, ilk başlanğıcda, ccpp-2014-12-08-16:32:57-11746 core dump folder-i yaradılır, core dump ora save olunur.
Lakin daha sonra ABRT GPG Key uyğunlunğunu yoxlayır, uyğunluq tapılmadığına görə yenicə save olunmuş core dump-ı onun folder-i ilə birlikdə silir.
Burada belə aydın olur ki, ABRT, 3rd Party (non-Red Hat və yaxud non-native) paketləri qeydə almır.
Sphinx özü düzgün, rəsmi paketlə install olunub. Lakin bu paket Red Hat (CentOS) tərəfindən təqdim olunmadığına görə key check-dən keçmir.
Bunu ABRT-nin config faylından da oxuya bilirik /etc/abrt/abrt-action-save-package-data.conf:

# With this option set to “yes”,
# only crashes in signed packages will be analyzed.
# the list of public keys used to check the signature is
# in the file gpg_keys
#
OpenGPGCheck = yes

Məlumata əsasən nəticə çıxardırıq ki, OpenGPGCheck = yes olduğu halda, GPG key check edir.
Bu yoxlanış isə gpg_keys faylına əsasən baş verir. Öz növbəsində /etc/abrt/gpg_keys faylının daxilində aşağıdakı məlumatlar yerləşir:

/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-6
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Security-6
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Testing-6

Ümumiləşdirsək,
OpenGPGCheck = yes -i no edib, ABRT-ni restart etsək, növbəti crash zamanı GPG key check olmayacaq və nəticədə Sphinx üçün core dump yaradılıb saxlanacaq.
Qeyd edim ki, bu üsulla istənilən 3rd Party məhsulun core dump-ı alınacaq. Yəni, mövzu sphinx üzərində izah olunsa da, sistem səviyyədə bütün paketlərə şamil olunur.
Core Dump aldıqdan sonra mövzunu davam etdirəcik.
Təşəkkürlər.