Dotaz: zatuhnutí v 24h intervalech

[jnovacek]

Přeinstaloval jsem openSUSE 10.3 na openSUSE11 z důvodu 24h intervalu zatuhávání systému. Nepodařilo se mi zjistit proč systém vytuhával v 9:20. Včera jsem vše přeinstaloval (čistá instalace) na openSUSE 11. Základní instalaci jsem dokončil cca v 11:45. Pak jsem doinstaloval sambu a LDAP. Vše jsem rozchodil a čekal co se stane dnes v 9:20. Nestalo se nic, vše fungovalo a já začal jásat. Jenže přiblížilo se 11:45 a systém opět přestal komunikovat. Jedná se přibližně o 24 hodin od dokončení základní instalace. Podotýkám, že server jsem x krát musel po doinstalovávání aktualizací a úprávách konfigurace restartovat. V příslušnou dobu server není zatížen ničím z venčí. Na monitoru výkonu jsem zjistil, že služba slapd si bere 25% což je proti 0%, které hlásí normálně hodně. Provedl jsem restart této služby a stejně se nic nestalo. Na stanicích se nedá přihlásit - doména není dostupná. Musím udělat restart. Jenže ani ten se nedokončí, systém se ne a ne vypnout. Žádné init nefunguje. Po odpojení od el. sítě a nastarování serveru vše opět jede. Předpokládám do zítra 11:45. Jak jsem již psal v minulých dotazech, nic na serveru nespouštím a ani cron nic nespouští. Jsem přesvědčen, že systém v pravidelných intervalech 24h od dokončení instalace začne něco dělat. Dokážete mi někdo poradit? Umí systém Linux pracovat bez vytuhnutí déle jak 24h? Je možné nějak zkontrolovat openLDAP databázi? Už si fakt nevím rady. Jediné co mně napadlo je, že server ještě jednou přeinstaluji a počkám s jeho doinstalováním třeba do 22:00. V tuto dobu zatuhnutí systému snad vadit nebude.
Moc prosím o radu.

Odpovědi

[Filip Jirsák]

Umí systém Linux pracovat bez vytuhnutí déle jak 24h?

Samozřejmě Sám píšete, že se v době výpadku pokoušíte se systémem dělat něco dalšího, takže ani váš případ není vytuhnutí linuxu, ale pouze nějaké služby.

Jediné co mně napadlo je, že server ještě jednou přeinstaluji a počkám s jeho doinstalováním třeba do 22:00.

Přeinstalací se problém nevyřeší. Přeinstalovávat počítač s Linuxem je většinou zbytečné, problém je v konfiguraci nějaké služby, stačí tu konfiguraci opravit – kvůli tomu není nutné celý systém přeinstalovávat.

Je možné nějak zkontrolovat openLDAP databázi?

Vyzkoušejte příkaz slapcat, ten vám vypíše celou LDAP databázi v LDIF formátu.

Zkontrolujte cron, zda se v uvedenou dobu něco nespouští, a zda není něco naplánováno přes atd.

Pokud je problém v LDAP serveru, napadají mne dvě možné příčiny – rotace logů a replikace. Máte něco takového nastavené?

Zkusil bych ručně (příkazem date) nastavit systémový čas třeba na 11:40 a počkat, zda se něco stane. Pokud ano, máte způsob, jak chybu snadno reprodukovat Pak bych vyzkoušel znovu to samé, ale vypnul bych openLDAP – abyste si potvrdil, že to způsobuje opravdu přímo tato služba. Pokud trik s posunem času nepomůže, zkusil bych zítra před 11:45 fyzicky odpojit počítač od sítě – abyste vyloučil vliv ostatních zařízení (třeba že se počítače v síti pokouší hromadně autorizovat a způsobí DDoS). Pokud posun času chybu vyvolá, bud problém s největší pravděpodobností přímo na vašem serveru, ale ještě nemusí být v LDAPu – může zlobit jiná služba, která na LDAPu vyvolá DoS.

Taky bude určitě užitečné prohlédnout si logy (systémové i logy služeb) okolo inkriminovaného času.

[vencour]

Ještě bych zkusil v inkriminovaný čas logovat co odkud kam komunikuje tcpdumpem třeba.

[jnovacek]

Včera jsem vyzkoušel posunout čas na 11:35 a čekal. Nestalo se nic. Dnes v 11:32 server zase zatuhnul. Může to být tím, že jsem včera špatně určil čas. Až všichni odejdou vyzkouším čas opět posunot (11:20) a čekat. Zajímavé je to, že se to děje skutečně v 24h intervalech. Bez ohledu na to, zda je server zapnutý až ráno nebo jede celou noc (Dnes jsem ho zapnul až v 7:30).
Na serveru jsem se znažil monitorovat zatížení. Včera jsem zjistil, že server zatěžuje slapd z 25%. Dnes jsem viděl jen vytuhnutý monitor výkonu. Musel jsem opět restartovat přes zásuvku, klasický softwarový restart opět nefungoval. Doopravdy se nic po 24h po doinstalování Linuxu nespouští?

[Filip Jirsák]

Musel jsem opět restartovat přes zásuvku, klasický softwarový restart opět nefungoval. Doopravdy se nic po 24h po doinstalování Linuxu nespouští?

V Linuxu jako takovém určitě ne, musela by to být záležitost distribuce. A distribuce by to spouštěla buď přes cron (ale tím se spouští pravidelně v určitý čas, takže by to bylo nezávislé na době instalace) nebo atd. Vše naplánované pro atd si (jako root) zobrazíte příkazem atq, plánovač cronu (pro aktuálního uživatele) si zobrazíte příkazem crontab -l.

Monitor výkonu je nějaká GUI aplikace? Zkusil bych se přepnout na konzoli a použít top, případně si přes ps ax vypsat všechny procesy – myslím, že to bude méně náročné na prostředky a spíše to projde, než nějaké GUI monitorovátko.

[jnovacek]

Příloha:

• priloha.txt (12705 bytů)

Na příkaz atq nedostanu žádnou odpověď. Na crontab -l dostanu no crontab for root a na aktuálně přihlášeného uživatele to samé. Ostatní jsou přihlášení jen prostřednictvím samba a ldap. Ten monitor výkonu jsem myslel ksysguard, jsem přihlášen v grafickém prostředí. Vyzkouším top a grafické prostředí nebudu spouštět. Používám distribuci openSUSE 11 a myslím si také, že je nesmysl, aby se po 24h něco spouštělo, ale pak to musí být obrovská náhoda.

[wolf09]

Jeste existuji /etc/cron.hourly,daily,weekly a take crony pro ostatni uzivatele.

Ja bych zkusil vypnout sluzbu crond a atd.

[Filip Jirsák]

Tyhle soubory se ale zpracovávají skriptem, který je spouštěn z cronu. V systémovém crontabu pravděpodobně budete mít něco jako

0  *  * * *     root    rm -f /var/spool/cron/lastrun/cron.hourly
1  3  * * *     root    rm -f /var/spool/cron/lastrun/cron.daily
15 4  * * 6     root    rm -f /var/spool/cron/lastrun/cron.weekly
30 5  1 * *     root    rm -f /var/spool/cron/lastrun/cron.monthly
*/10  *  * * *  root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons

[Filip Jirsák]

Vždycky jsem si myslel, že /etc/crontab je crontab roota, ale on je systémový a rootovský crontab oddělen. Tak se ještě podívejte na /etc/crontab, ale tam pravděpodobně budete mít nastavené jen spouštění hodinových, denních, týdenních a měsíčních úloh. Na ně se ale určitě podívejte (spoléhal jsem na to, že se k nim dostanete přes crontab), protože tam se spouštějí úlohy jako rotace logů nebo indexování, což by mohlo s vaším problémem souviset.

[Filip Jirsák]

Ještě k těm logům – je tam restart syslog-ng, to jste způsobil vy, nebo se to restartovalo „samo“?

Pak je tam řádek su: (to beagleindex) root on none – z toho bych soudil, že se spustilo indexování, a tedy že se spouští úlohy naplánované aby běžely 1 denně – podívejte se na ně (/etc/cron.daily), případně je zkuste odstranit a postupně přidávat (někam ty soubory přesuňte a pak je vracejte zpět), nebo ještě lépe zkusit ty skripty spustit ručně (se stejnými právy, s jakými je spouští cron, tedy pod rootem, jestli to tak máte uvedeno v /etc/crontab).

[Arno3t]

Moje reakce na váš dotaz vám bezprostředně nepomůže, ale stalo se mi něco podobného asi před dvanácti lety. Nechal jsem v CD mechanice CD a kdykoliv se okolo páté ráno vytvářel index souborů příkazem find, došlo v jistém adresáři na CD k pádu sytému. Trvalo mi asi měsíc než jsem na to přišel. V pět jsem do práce nikdy nechodil. Byla to podivná chyba Linuxu, kterou se bez toho CD nepovedlo zopakovat. Taková se vývojářům asi těžko hledá (pokud jim to CD nepošlete). V každém případě hledání v cronu bude asi správná cesta. Nevím jak je určen čas pro aplikace v cron.daily, ale ze zkušenosti bych řekl, že je to čas definovaný nějak pseudonáhodně při bootu nebo instalaci a pak už má železnou pravidelnost? Třeba nám to tady někdo objasní (jo, právě teď jsem líný to googlit a číst odpovídající skripty).

[Jooky (inactive)]

Pokial sa pouziva nieco na styl /usr/sbin/run-crons (tak ako to napr. mam v gentoo) tak presne spominana pravidelnost moze byt sposobena tymto pristupom. Ten script je pravidelne pustani z cronu kazdych 10 minut a podla timestampu v /var/spool/cron/lastrun/ (napr. /var/spool/cron/lastrun/cron.daily) urcuje dalsi beh. Ak od posledneho behu uz ubehol cas intervalu (napr. 24h pre daily) tak script spusti naplanovane ulohy. Ak neni ten timestamp ovplivnovany nicim inym (aj napr tym ze system neni zapnuty v ten cas kedy sa ma pustit) tak pravidelne kazdy den v ten isty cas spusta scripty v /etc/cron.daily/

Trosku sa mozno budem opakovat ale pre istotu. Na zaciatok doporucujem povypinat automaticke akcie na systeme. Uz spominany cron (daily sa tusim pustaj aj updatedb, ktory prelieza cely stroj aby spravil db suborov pre locate). Ak aj tak nenajdete problem, tak hladat v sw co tam bezi, ci nesposobuje ten problem (napr. vycerpanie pamate pri nejakom automatizovanom ukone nad ldap, alebo problem s hw pri teste cez smartd, ...). Pricin moze byt viacej a prinajhorsom moze pomoct aj zazracna klavesa SysRq (ak ostane jadro v rozumnom stave).

[AraxoN]

Stalo sa mi podobné celkom nedávno na jednom staršom serveri u zákazníka - vždy v noci vytuhol a keďže sa jedná o nonstop prevádzku tak obsluha vždy musela zísť do suterénu a server resetovať buttonom na bedni. Považovali to za normál (inu - Windows useri), takže o tom začali hovoriť asi tak po 2 mesiacoch, keď ich to ale naozaj už prestalo baviť. Príčinou bolo to, že sa v cron.daily spúšťal updatedb, ktorý prechádzal celý disk - a jeden z dvoch diskov v RAID-1 bol na jednom mieste vadný. To miesto sa za normálnych okolností nečítalo, ale stačilo vojsť do inkriminovaného adresára a nasledoval výtuh. Obskurný pseudo-RAID (hpt370) si s tým nevedel poradiť, našťastie po pripojení diskov normálne sa ukázalo, že vadný je len jeden, takže sa im spravil nový server a na neho sa to nakopírovalo z toho druhého disku.

Suma sumárum: je dosť možné, že ide o HW chybu. Skúste len tak zo srandy updatedb, či to pri ňom vytuhne - ak áno, tak je najvyšší čas začať zachraňovať dáta.

[jnovacek]

Děkuji všem za návrhy jak tento broblém vyřešit. Domníval jsem se, že se cron spoští pouze když je něco v crontab. Po odstranění cron vše jelo. Tak jsem začal testovat jednotlivé služby v adresáři cron.daily. Spouštěl jsem je pod rootem tak, že jsem je odkliknul v mc. Všechny až na jednu projdou a nic neudělají. Jedna vyhodí několikrát error a stane se příslušné zatuhnutí. Jedná se o logrotate.
#!/bin/sh

TMPF=`mktemp /tmp/logrotate.XXXXXXXXXX`

/usr/sbin/logrotate /etc/logrotate.conf 2>&1 | tee $TMPF
EXITVALUE=${PIPESTATUS[0]}

if [ $EXITVALUE != 0 ]; then
# wait a sec, we might just have restarted syslog
sleep 1
# tell what went wrong
/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
/bin/logger -t logrotate -f $TMPF
fi

rm -f $TMPF
exit 0
Kde najdu log k této činnosti.
Mohu ho odstranit aniž dojde k nějakým problémům?
Předem děkuji

[jnovacek]

Jak se dá nastavit čas provádění u cron.daily.

[Filip Jirsák]

Podívejte se do /etc/crontab – měl by se spouštět odsud. Buď tam může být zadaný přesný čas, ale podle chování tam spíš bude nějaké pravidelné spouštění skriptu (třeba po 10 minutách) a skript sám si už zjistí, jak dlouhá doba uplynula od posledního spuštění cron.hourly, cron.daily atd. a případně je spustí.

[jnovacek]

Příloha:

• run-crons (7510 bytů)

v crontab mám toto
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1

můj předpoklad je, že se spouští každých 15 min. Je možné to nějak přepsat aby se cron.hourly spouštěl pomocí tohoto testování, ale ostatní daily, weekly a monthly třeba v 22:00
Obsah run-crons je v příloze. Je případně možné úplně vynechat cron.hourly? Je tam jen mcelog obsahující toto
#!/bin/bash
/usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
což opět netuším co dělá. Upravit potom crontab už pak není problém.

[Filip Jirsák]

Čas, kdy se má spouštět cron.daily můžete nastavit nastavením proměnné DAILY_TIMEv etc/sysconfig/cron (třejmě ve formátu 2200). Ostatní byste asi mohl načasovat manipulací s datem souborů v /var/spool/cron/lastrun – měly by mít nastavené datum a čas posledního spuštění, od toho data a času se počítá, kdy se má skript spustit příště. Ovšem dejte pozor, nastavení času do budoucnosti může skript rozhodit, naopak nastavení o více než jeden interval do minulosti (např týdenní skript posunout o více jak týden zpět) bude znamenat, že se skripty spustí při příštím spuštění tohoto skriptu (tedy do 15 minut).

Je případně možné úplně vynechat cron.hourly?

Jednoduše vymažte (nebo přesuňte) všechny skripty, které jsou v /etc/cron.hourly.

Ale snažil bych se najít spíš příčinu zatuhnutí systému, přesunout to na nějakou „méně škodlivou“ dobu není řešení. odstraňujete pouze důsledek, ne příčinu, a ta příčina se může znova objevit někde jinde v úplně jiné podobě, a zpravidla s daleko horšími následky.

[AraxoN]

Jedna vyhodí několikrát error a stane se příslušné zatuhnutí.

Práve ten error asi bude podstatný - ten sem nakopíruj.

[jnovacek]

Příslušný error jsem si zazálohoval. Restartoval server, ale soubor tam po restartu nebyl. Proto jsem ho sem nemohl dát.
Horší je, ale to, že po restartu jsem vyzkoušel všechny služby a zatuhnutí nenastalo. Dnes jsem vyzkoušel opět všechny služby a nic. Budu muset počkat do zítra, kdy je server zatížen a otestovat to znovu. Třeba se to po několikátém spuštění příslušné služby vyřešilo samo.

[jnovacek]

Ráno jsem zjistil, proč to šlo nejspíš spustit bez problému, odstřelil se mysql server. Musím počkat až do odpoledne na další testování.

[Filip Jirsák]

Výstup se zapisuje do logu logrotate – vizte

/bin/logger -t logrotate -f $TMPF

Podívejte se na konfigurační soubor /etc/logrotate.conf, zda tam není něco špatně.

[stativ]

Pošli sem /etc/logrotate.conf.

V nejhorším případě můžeš logrotate z cronu vyhodit (není to kritická služba), v podstatě slouží jenom k přejmenovávání starých logů.

Problém si myslím může být v tom, že se logrotate snaží rotovat nějaký log, do kterého se ve stejnou chvíli zapisuje.

[jnovacek]

Příloha:

• logrotate.conf (782 bytů)

obsah logrotate.conf

[stativ]

Hmm… co máš v /etc/logrotate.d ?

[jnovacek]

Příloha:

• mysql (1058 bytů)

jedná se o adresář a obsahuje toto:
-rw-r--r-- 1 root root 1097 Jun 7 03:55 apache2
-rw-r--r-- 1 root root 260 Jun 6 23:41 icecream
-rw-r--r-- 1 root root 196 Jun 6 23:52 mcelog
-rw-r--r-- 1 root root 1058 Sep 6 01:32 mysql
-rw-r--r-- 1 root root 187 Jun 7 02:57 ntp
-rw-r--r-- 1 root root 225 Jun 7 01:19 openslp-server
-rw-r--r-- 1 root root 1031 Jun 7 02:08 quagga
-rw-r--r-- 1 root root 141 Jun 7 05:23 rsync
-rw-r--r-- 1 root root 289 Aug 27 19:35 samba
-rw-r--r-- 1 root root 148 Aug 27 19:35 samba-winbind
-rw-r--r-- 1 root root 129 Jun 7 03:39 scpm
-rw-r--r-- 1 root root 1113 Jun 6 22:36 syslog
-rw-r--r-- 1 root root 551 Jun 7 00:13 syslog-ng
-rw-r--r-- 1 root root 184 Jun 16 14:20 vsftpd
-rw-r--r-- 1 root root 134 Jun 6 22:52 wtmp
-rw-r--r-- 1 root root 140 Jul 23 2004 xdm
-rw-r--r-- 1 root root 200 Jun 6 23:18 xinetd
-rw-r--r-- 1 root root 134 Jul 21 18:05 zypper.lr
Nebudu posílat vše, ale třeba mysql je v příloze

[Heron]

Prošel jsem celou diskusi a jak to tak vypadá, tak se vám seká LDAP server (nikoliv Linux) při logrotate. V Suse nevím, ale na CentOS stačí dát "service ldap recovery" (pro check DB ldapu). Zkuste jej také odstranit z logrotate, případně jej vypněte (služby pojedou, jen budou logovat do jednoho souboru a nic ne nebude automaticky mazat).

[jnovacek]

skoro týden to jede bez jediného zatuhnutí. Jediné co jsem udělal je to, že jsem odstřelil cron. Když to vytuhávalo, tak restartování služeb nefungovalo a ani počítač se normálně nedal vypnout. LDAP byl vytvářen úplně znova z generovaného ldif souboru (žádná záloha s chybama). Hned po cronu server zatuhnul.

[Filip Jirsák]

Vypnout cron ale podle mne není nejlepší způsob řešení tohoto problému. Ten problém způsobuje nějaký skript spouštěný z cronu (pravděpodobně logrotate). Problém může být třeba i v tom, že logrotate se může pokoušet zastavit a znovu spustit službu, které rotuje log, takže problém může být třeba ve startu LDAP serveru. Takže zastavení cronu sice problém „odstraníte“, ale chyba se může projevit znovu třeba až bude mět počítač nastartovat po nějakém výpadku proudu, tedy v nejnevhodnější okamžik.

[stativ]

Hmm… doufal jsem, že tam bude něco od LDAPu. Začnu tím, co je mi podezřelé – existence syslog a syslog-ng, používat by se měl jenom jeden. Pmožná opravdu jenom jeden běží, v tom případě je ale zbytečné mít nainstalované oba, takže řekl bych, že můžeš odstranit syslog (měl by se používat syslog-ng). Problémy by mohl dělat také mcelog.

Jelikož tam ale, jak už jsem říkal, nevidím LDAP, tak asi jedinou možností jak zjistit, jestli problémy dělá rotace nějakého logu bude všechny soubory z /etc/logrotate.d někam přesunout a pak postupně je zase po jednom vracet a čekat, kdy po spuštění logrotate bude docházet k chybám.

[jnovacek]

Eror z příkazového řádku po provedení logrotate. Nedojde k návratu do příkazového řádku a systém přestane poskytovat doménu. Nedá se přihlásit: Doména není k dispozici.

a01l:/srv/samba/data/cron/cron.daily # ./logrotate
Module "ruby" is not installed, ignoring.
Check the APACHE_MODULES setting in /etc/sysconfig/apache2.
Reload httpd2 (graceful restart)..done
Module "ruby" is not installed, ignoring.
Check the APACHE_MODULES setting in /etc/sysconfig/apache2.
Reload httpd2 (graceful restart)..done
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
/etc/logrotate.d/mysql failed, probably because
the root acount is protected by password.
See comments in /etc/logrotate.d/mysql on how to fix this
error: error running non-shared postrotate script for /var/lib/mysql/mysqld.log of '/var/lib/mysql/mysqld.log '
Reload syslog service..done



[Filip Jirsák]

Dojde zřejmě k chybě při startu služby syslog – možná se čeká, až se ukončí všechny služby, které do syslogu zapisují, nebo něco takového. Pokud zkusíte syslog restartovat distribučním skriptem, podaří se to? Jakým způsobem jste vlastně logovací službu a logrotate instaloval? Nezdá se mi, že by to nějaká distribuce neměla vyřešené. Osobně navíc logrotate vůbec nepoužívám, nelíbí se mi ten princip, že se kvůli rotaci logů restartují služby – raději používám logovací systém, který umí logy rotovat sám.

[jnovacek]

Vše jsem instaloval pomocí průvodce. Nejsem žádný specialista. Co jsem naklikal v openSUSE, to tam je, nic jsem tam ručně nepřidával ani jsem nic neupravoval.
Jak to mám předělat, aby to fungovalo bez restartu služeb? Jaký logovací systém mám použít? Respektive jak vypnout ten co tam mám? Stačí odstranit logrotate?

[Filip Jirsák]

Nemá openSUSE v balíčcích třeba metalog? Ten umí určitě rotovat logy sám. Pak byste snad mohl klidně logrotate vypnout. Pokud tedy Apache a MySQL umí logovat i skrze systémový logger.