Arxiv
2014 in review
The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.
Here’s an excerpt:
A New York City subway train holds 1,200 people. This blog was viewed about 5,200 times in 2014. If it were a NYC subway train, it would take about 4 trips to carry that many people.
Connecting to ILO with firefox on Ubuntu: the Java issue
İLO nədir? (bax. Wikipedia)
Ubuntu 14.04-də Firefox versiya 34.0-dən İLO-ya qoşulub, Virtual Media-dan İSO image əlavə etmək istədikdə naməlum qara pəncərə gəlir və heç bir əlavə funksionallığı olmur.
Qeyd edək ki,
java-7-openjdk-amd64
icedtea-7-plugin
İnstall olunub.
Mövzunu addım-addım getməliyik ki, problemə mərhələli yanaşmanı da göstərmiş olaq.
IcedTea plugin-inin rəsmi dokumentasiyasına əsasən, IcedTeaPlugin.so faylı mozilla-nın plugin direktoriyasındakı libjavaplugin.so faylına symlink olunmalıdır:
sh@sh--work:~$ cd /usr/lib/mozilla/plugins sh@sh--work:~$ ln -s /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so libjavaplugin.so sh@sh--work:/usr/lib/mozilla/plugins$ ls -l | grep libjavaplugin.so lrwxrwxrwx 1 root root 64 Dec 12 15:52 libjavaplugin.so -> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Verilmiş tələbi yerinə yetirdikdən sonra, Java-nın hansı error-ları verdiyini müəyyən etmək üçün, IcedTea pluginin debug halda aktiv edib Firefox-u start etməliyik.
Əgər hal-hazırda firefox açıqdırsa onu kill edin və terminaldan aşağıdakı qaydada yenidən start edin:
ICEDTEAPLUGIN_DEBUG=true firefox 2>&1 | tee plugin.log
Yuxarıdakı komandaya əsasən plugin.log faylı yaranacaq. Log faylından hansı problemlərin olduğunu müəyyən edə biləcik.
İlk error aşağıdakı kimidir:
java.text.ParseException: Unparseable date: "cüm Dek 12 15:02:15 AZT 2014" at java.text.DateFormat.parse(DateFormat.java:357) at net.sourceforge.jnlp.util.logging.headers.PluginMessage.<init>(PluginMessage.java:73) at net.sourceforge.jnlp.util.logging.JavaConsole.processPluginMessage(JavaConsole.java:523) at net.sourceforge.jnlp.util.logging.JavaConsole.access$1100(JavaConsole.java:87) at net.sourceforge.jnlp.util.logging.JavaConsole$13.run(JavaConsole.java:554) at java.lang.Thread.run(Thread.java:745)
Unparseable date: “cüm Dek 12 15:02:15 AZT 2014” – Məndə Local olaraq ayın tarixinin göstərilməsi Azərbaycan dilinə uyğundur. Görünən budur ki, bunu tanımır.
Dolayısı ilə bunu dəyişməliyik:
Settings — Language Support — Regional Formats-dan dəyişiklik edib English(United States) edirik.
Yenidən aktiv Firefox-u kill edin, yenidən DEBUG mode-da restart edin. Görəcəksiniz ki, yuxarıdakı error aradan qalxdı.
Keçirik log faylda rastlanan 2ci error-a:
java.io.FileNotFoundException: /home/sh/.config/icedtea-web/deployment.properties (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:146) at java.io.FileReader.<init>(FileReader.java:72) at net.sourceforge.jnlp.config.DeploymentConfiguration.parsePropertiesFile(DeploymentConfiguration.java:650) at net.sourceforge.jnlp.config.DeploymentConfiguration.findSystemConfigFile(DeploymentConfiguration.java:474) at net.sourceforge.jnlp.config.DeploymentConfiguration.load(DeploymentConfiguration.java:287) at net.sourceforge.jnlp.config.DeploymentConfiguration.load(DeploymentConfiguration.java:257) at net.sourceforge.jnlp.runtime.JNLPRuntime$DeploymentConfigurationHolder.initConfiguration(JNLPRuntime.java:394) at net.sourceforge.jnlp.runtime.JNLPRuntime$DeploymentConfigurationHolder.<clinit>(JNLPRuntime.java:389) at net.sourceforge.jnlp.runtime.JNLPRuntime.getConfiguration(JNLPRuntime.java:424) at net.sourceforge.jnlp.config.DirectoryValidator.<init>(DirectoryValidator.java:224) at net.sourceforge.jnlp.config.DeploymentConfiguration.move14AndOlderFilesTo15Structure(DeploymentConfiguration.java:824) at net.sourceforge.jnlp.config.DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched(DeploymentConfiguration.java:728) at sun.applet.PluginMain.main(PluginMain.java:139)
Araşdırmama əsasən bu error-un qarşısını İcedTea-ni configləməklə almaq olur.
İcedTea özünün xüsusi config proqramı ilə gəlir aşağıdakı kimi run etmək lazımdır:
sh@sh–work:~$ itweb-settings
Ilk öncə Security hissəsindən default High olan hissəni Low edirik.
(QEYD: ILO ilə işinizi bitirdikdən sonra, mütləq bu göstəricini geri qaytarın)
Daha sonra JVM settings-dən local JRE folder-in path-ını veririk:
Apply edirik, save edirik və yenidən firefox DEBUG halda start edirik.
Yeni error log faylından belə görürük ki, yuxarıdakı error da aradan qalxdı. Lakin hələ də biz Virtual Media-əlavə edə bilmirik.
Daha dəqiq print screen-dəki davam edir:
Error log-a baxmağa davam edirik və daha bir maraqlı erroru görürük:
java.lang.UnsatisfiedLinkError: /tmp/cpqma-1c6dc3fa: /tmp/cpqma-1c6dc3fa: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1851) at java.lang.Runtime.load0(Runtime.java:795) at java.lang.System.load(System.java:1062) at com.hp.ilo2.virtdevs.DirectIO.<clinit>(DirectIO.java:87) at com.hp.ilo2.virtdevs.MediaAccess.devices(MediaAccess.java:183) at com.hp.ilo2.virtdevs.virtdevs.ui_init(virtdevs.java:363) at com.hp.ilo2.virtdevs.virtdevs.start(virtdevs.java:142) at sun.applet.AppletPanel.run(AppletPanel.java:476) at java.lang.Thread.run(Thread.java:745)
Bu error Java-nın bit versiyasının problemidir. Yəni, əgər diqqət etdinizsə biz, 64 bit-lik JRE istfadə edirdik. Burdan belə nəticə çıxır ki, 32-bitlik JRE ilə bu error-u aradan qaldıra bilərik. Bunun üçün 32-bitlik Java-nı install edək:
sh@sh–work:~$ sudo apt-get install openjdk-7-jre:i386
Daha sonra İcedTea-nin config-ini dəyişək və yeni 32-bitlik JRE path-i əlavə edək:
Bir daha Firefox-u restart edib yoxlasaq görərik ki, əvvəlki boş screen yenisi ilə əvəzləndi.
İndiki halda biz məqsədimizə çatmış olduq.
İşlədiyim müddətdə əlavə maraqlı həllər olarsa, onları yazıya əlavə edəcəm.
Həmçinin ola bilsin mövzunun daha yeni davamı olsun.
Təşəkkürlər.
Missing Sphinx debug package – building from source
Sphinx-lə əlaqədar olan ilk yazımızda Sphinx crash zamanı core dump-ı ala bilməməkdən danışmışdıq(bax. abrtd: Package ‘sphinx’ isn’t signed with proper key)
Core Dump aldıqdan sonra, GDB ilə debug etməyə çalışdıqda:
[root@xxxx ccpp-2014-12-10-21:53:04-8871]# gdb /usr/bin/searchd coredump GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6) This GDB was configured as "x86_64-redhat-linux-gnu". Reading symbols from /usr/bin/searchd...(no debugging symbols found)...done. [New Thread 8871] [New Thread 8874] [New Thread 8877] [New Thread 8878] [New Thread 8873] [New Thread 8875] [New Thread 8876] Core was generated by `/usr/bin/searchd --config /etc/sphinx/sphinx.conf'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004c790d in CheckFlush() () Missing separate debuginfos, use: debuginfo-install sphinx-2.1.8-1.rhel6.x86_64 (gdb) bt #0 0x00000000004c790d in CheckFlush() () #1 0x000000000050c61f in TickHead(bool) () #2 0x000000000050ed16 in ServiceMain(int, char**) () #3 0x000000000050ffad in main () (gdb) bt full #0 0x00000000004c790d in CheckFlush() () No symbol table info available. #1 0x000000000050c61f in TickHead(bool) () No symbol table info available. #2 0x000000000050ed16 in ServiceMain(int, char**) () No symbol table info available. #3 0x000000000050ffad in main () No symbol table info available.
Bəzi debug paketləri yoxdur – Missing separate debuginfos, use: debuginfo-install sphinx-2.1.8-1.rhel6.x86_64.
Nəzərə alsaq ki, Sphinx 2.1.8 debug paketi repo-larda da yoxdur, o zaman bu paketi özümüz build etməli olacıq. Məqsədimiz coredump-ı daha düzgün şəkildə debug edə bilməmizdi.
Yeni yaratdığımız rpm-lərlə əvvəlkini əvəzləyəcik(replace) və eyni crash baş verdikdən sonra yeni coredump-la araşdırmamızı davam etdirəcik.
Source-dan özümüz debuginfo paketinin rpm-ini yaradaq və bunu install edək.
Bu məqsədlə lazımı paketləri yazaq:
[root@xxxx ~]# yum install rpm-build rpmdevtools
Sphinx builder user-ini tələb edir bu user-i yaradaq:
[root@xxxx ~]# adduser builder [root@xxxx builder]# su - builder
Source faylımızı download edək:
[builder@xxxx ~]$ wget http://sphinxsearch.com/files/sphinx-2.1.8-1.rhel6.src.rpm [builder@xxxx ~]$ ls sphinx-2.1.8-1.rhel6.src.rpm
Source faylı install edək:
[builder@xxxx ~]$ rpmdev-setuptree [builder@xxxx ~]$ ls rpmbuild sphinx-2.1.8-1.rhel6.src.rpm [builder@xxxx ~]$ rpm -ivh sphinx-2.1.8-1.rhel6.src.rpm 1:sphinx ########################################### [100%]
Əgər diqqət etsək .spec faylının yarandığını görərik:
[builder@xxxx rpmbuild]$ ls BUILD RPMS SOURCES SPECS SRPMS [builder@xxxx rpmbuild]$ ls SPECS/ sphinx_rel21.spec
Spec faylından istifadə etməklə rpm-lərimizi yaratmağa çalışaq:
[builder@xxxx rpmbuild]$ rpmbuild -ba SPECS/sphinx_rel21.spec error: Failed build dependencies: mysql-devel is needed by sphinx-2.1.8-1.el6.x86_64 postgresql-devel is needed by sphinx-2.1.8-1.el6.x86_64 expat-devel is needed by sphinx-2.1.8-1.el6.x86_64
Aydın olur ki, mysql-devel , postgresql-devel, expat-devel paketlərini yazmalıyıq.
Nəzərə alsaq ki, bizim Sphinx-imiz MySQL ilə çalışır və postgresql-devel paketi postgresql tələb edir. postgresql bizə lazım olmadığı üçün onu dependency requirement-dən çıxarmaq lazımdır. Bu məqsədlə sphinx_rel21.spec faylında postgresql-devel paketini comment-ləmək lazımdır:
#BuildRequires: postgresql-devel
Bir daha yuxarıdakı komandanı run etsək:
[builder@xxxx rpmbuild]$ rpmbuild -ba SPECS/sphinx_rel21.spec
error: Failed build dependencies:
mysql-devel is needed by sphinx-2.1.8-1.el6.x86_64
expat-devel is needed by sphinx-2.1.8-1.el6.x86_64
yum install mysql-devel expat-devel – bu dependency problemimiz həll edəcək.
Daha sonra bir daha eyni komandanı işlədək, lakin bir dəyişiklik etmək lazımdır.
Məntiqlə düşündükdə biz, PostgreSQL paketlərini dependency kimi çıxartdıq, lakin configure zamanı bunu göstərməliyik ki, source-dan compile etdikdə PostgreSQL paketlərinə müraciət etməsin.
Yenidən biz .spec faylımızı açırıq orada %build kataloqu altında %configure axtarırıq.
%configure –sysconfdir=/etc/sphinx –with-mysql –with-re2 –with-libstemmer –with-unixodbc –with-iconv –enable-id64 –with-pgsql –with-syslog
Gördüyümüz kimi, –with-pgsql opsiyasını –without-pgsql olaraq dəyişirik. Həmçinin, –enable-debug əlavə edirik.
%build kataloqundan yuxarıda isə %debug_package əlavə edirik.(bu debug paketinin yaradılması üçün lazımdır). .spec faylı save edirik.
Həmçinin bildiyiniz kimi, build və make əməliyyatları üçün aşağıdakı paketlərə də ehtiyac var:
yum install gcc gcc-g++ make cpp
Bütün addımları etdikdən sonra RPM paketlərimizi yaradaq:
[builder@xxxx rpmbuild]$ rpmbuild -ba SPECS/sphinx_rel21.spec . . . Wrote: /home/builder/rpmbuild/SRPMS/sphinx-2.1.8-1.el6.src.rpm Wrote: /home/builder/rpmbuild/RPMS/x86_64/sphinx-2.1.8-1.el6.x86_64.rpm Wrote: /home/builder/rpmbuild/RPMS/x86_64/sphinx-testing-2.1.8-1.el6.x86_64.rpm Wrote: /home/builder/rpmbuild/RPMS/x86_64/sphinx-debug-2.1.8-1.el6.x86_64.rpm
Əməliyyatlar uğurla nəticələnsə RPMS folderində aşağıdakı fayllar olacaq:
[builder@xxxx rpmbuild]$ ls -l RPMS/x86_64/ total 36924 -rw-rw-r-- 1 builder builder 7666291 Dec 11 13:35 sphinx-2.1.8-1.el6.x86_64.rpm -rw-rw-r-- 1 builder builder 28716729 Dec 11 13:35 sphinx-debug-2.1.8-1.el6.x86_64.rpm -rw-rw-r-- 1 builder builder 1422134 Dec 11 13:35 sphinx-testing-2.1.8-1.el6.x86_64.rpm
Gördüyümüz kimi hem sphinx həm də sphinx-debug paketlərini əldə etmiş olduq.
Mövcud Sphinx paketini yenisi ilə əvəz etdikdən və debug paketi install etdikdən sonra, yeni crash-dən sonra yazının əvvəlindəki kimi faydasız GDB analizi yox full analiz etmək mümkün olur:
[root@xxxx ccpp-2014-12-11-14:30:45-59208]# gdb /usr/bin/searchd coredump
Reading symbols from /usr/bin/searchd...Reading symbols from /usr/lib/debug/usr/bin/searchd.debug...done.
done.
[New Thread 59208]
[New Thread 59209]
[New Thread 59211]
[New Thread 59210]
[New Thread 59213]
[New Thread 59214]
[New Thread 59212]
Core was generated by `/usr/bin/searchd --config /etc/sphinx/sphinx.conf'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000420c12 in CheckFlush () at searchd.cpp:18828
18828 if ( g_pFlush->m_bFlushing )
(gdb) bt
#0 0x0000000000420c12 in CheckFlush () at searchd.cpp:18828
#1 0x000000000046731a in TickHead (bDontListen=false) at searchd.cpp:19825
#2 0x0000000000468cee in ServiceMain (argc=985764272, argv=<value optimized out>) at searchd.cpp:21072
#3 0x000000000046a621 in main (argc=3, argv=0x7fff3ac1a718) at searchd.cpp:21143
(gdb) bt full
#0 0x0000000000420c12 in CheckFlush () at searchd.cpp:18828
bDirty = <value optimized out>
#1 0x000000000046731a in TickHead (bDontListen=false) at searchd.cpp:19825
iClientSock = <value optimized out>
sClientName = "85.132.89.226:35563\000\000"
pListener = <value optimized out>
#2 0x0000000000468cee in ServiceMain (argc=985764272, argv=<value optimized out>) at searchd.cpp:21072
iBacklog = 5
tQueryTLS = {m_tQuery = {m_pQuery = 0x0, m_iSize = 0, m_uCMD = 0, m_uVer = 0, m_bMySQL = false},
static m_tForkQuery = {m_pQuery = 0x7f75ff26ddc5 "", m_iSize = 202, m_uCMD = 0, m_uVer = 279,
m_bMySQL = false}, static m_tLastQueryTLS = 6}
bOptStatus = <value optimized out>
iOptPort = <value optimized out>
uReplayFlags = <value optimized out>
hConf = @0x9b27a0
bOptStop = <value optimized out>
bWatched = 176
tListener = {m_iSock = 985769744, m_eProto = PROTO_SPHINX}
sArenaError = <value optimized out>
pAcceptMutex = 0x0
bOptPort = <value optimized out>
hIndexes = {<CSphOrderedHash<CSphIndex*, CSphString, CSphStrHashFunc, 256>> = {m_dHash = {
0x0 <repeats 33 times>, 0x2119ad0, 0x0 <repeats 31 times>, 0x2119cb0, 0x0, 0x0, 0x0, 0x0, 0x2119d70,
0x0 <repeats 17 times>, 0x2119b30, 0x0 <repeats 20 times>, 0x2119bf0, 0x0 <repeats 13 times>,
0x2119a10, 0x0 <repeats 46 times>, 0x2119a70, 0x0 <repeats 35 times>, 0x2119b90, 0x0, 0x2119dd0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x2119d10, 0x0 <repeats 35 times>, 0x2119c50, 0x0, 0x0, 0x0, 0x0},
m_pFirstByOrder = 0x2119a10, m_pLastByOrder = 0x2119dd0, m_iLength = 11,
m_pIterator = 0x0}, <No data fields>}
bOptStopWait = <value optimized out>
i = <value optimized out>
hSearchdpre = <value optimized out>
bVisualLoad = false
conf = {<CSphOrderedHash<SmallStringHash_T<CSphConfigSection>, CSphString, CSphStrHashFunc, 256>> = {
m_dHash = {0x0 <repeats 256 times>}, m_pFirstByOrder = 0x0, m_pLastByOrder = 0x0, m_iLength = 0,
m_pIterator = 0x0}, <No data fields>}
---Type <return> to continue, or q <return> to quit---
bOptPIDFile = 208
dOptIndexes = {m_iLength = 0, m_iLimit = 0, m_pData = 0x0}
sOptListen = {_vptr.CSphString = 0x98b190, m_sValue = 0x0, static SAFETY_GAP = 4}
bOptListen = <value optimized out>
bTestMode = <value optimized out>
iDevNull = 34607408
hSearchd = <value optimized out>
#3 0x000000000046a621 in main (argc=3, argv=0x7fff3ac1a718) at searchd.cpp:21143
cTopOfMainStack = 0 '\000'
Artıq müəyyən elədik ki, crash səbəbi,
#0 0x0000000000420c12 in CheckFlush () at searchd.cpp:18828
18828 if ( g_pFlush->m_bFlushing )
searchd.cpp adlı faylın 18828 -ci sətrindəki if statement-dir.
Həmçinin görürük ki,
#0 0x0000000000420c12 in CheckFlush () at searchd.cpp:18828
bDirty =
bDirty – Dirty İndex-i təyin edən boolean dəyişəndir və.s şəkildə source kodu araşdırmaqla kod məntiqini başa düşmək lazımdır.
Daha sonra da, crash səbəbini müəyyən etmək olar, hətta bu əgər BUG-dırsa BUG report edə bilərsiniz.
Crash hər hansı üsulla həll edilsə, onun həlli haqqında da ayrıca danışacıq.
Təşəkkürlər.
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.
Oracle/MySQL Blog 