Start systému skončí na "starting crond"

Ahoj,

mám velkou prosbu. Známý si provozuje server na CentOS (pošta, dns, web, db), ale vše dělal podle návodů, jinak je jen obyčejný uživatel jako já a teď po výpadku elektriky mu start systému skončí na “starting crond”, do té doby vše OK. Na tomto startu visí hodinu, dvě, prostě stále. Když jsme dali Ctrl-Alt-Del, tak normálně začne shutdown sekvence a bez problému se ukončí. Chtěl po mě poradit, došel jsem, trápil jsem se s tím dvě hodiny a bez úspěchu. Do single user módu to dostanu bez problému (stáhl jsem si na disketu boot.log a message a mám je u sebe). Při hledání jsem narazil na informaci, že by za tím mohl být ntpd, ale při běžném startu má OK, v single user módu service ntpd restart projde, zde jsem zkoušel i service crond start také projde úspěšně.

Poraďte prosím, kam se podívat. Žádný crond log jsem nenašel, abych se podíval, na co donekonečna čeká.

Je možné v situaci, kdy při startu to visí na hlášce “starting crond” zmáčknout něco jiného než Ctrl-Alt-Del, abych tomu startu nějak pomohl?

Zálohu systémového disku nemá, nepovažoval to za nutné, protože má dva v raidu.

Díky moc za jakoukoliv radu.

Dají se spouštět jednotlivé služby.

V jednu chvíli ti tam svítí Press “I” for interactive startup nebo tak nějak.
Hned potom najíždí udev a svítí zelené(většinou :slight_smile: ) OK.

Díky za odezvu, ani nevíš, jak jsem vděčný. Když jsem v single user módu, mohu si dělat co chci, ostatně to jsem psal, že jsem restartoval ntpd. Samozřejmě většina služeb a nastavení je dole. Na to spuštění interaktivního režimu se večer podívám, teď si nejsem jistý. A ano svítí zelené OK všude, dokud to nenajede na starting crond, tam nesvítí nic, ani OK ani FAILED, jen čeká a čeká. Snažil jsem se najít, co konkrétne ten crond spouští, že bych mu pomohl, … potlačil …

Záznam jednoho pokusu o normální start z boot.log a message je dole. je vidět, že v 21:10 přestane komunikovat a v 21:21 mě to přestalo bavit a stiskl jsem Ctrl-Alt-Del a on začal normálně zavírat. Právě ale kernel time v 21:14 a 21:15 v message mě vedl k tomu zkusit v single user módu, zda jde spustit services ntpd. Pochopitelně tam neběží, takže restart nejprve nemá co shazovat, nenajde server a spustí se, napodruhé shodí (OK), nenajde server, ale v single user módu to chápu, nejede internet (FAILED) a spustí se (OK).

Prosím, jsem vděčný za jakýkoliv nápad.

boot.log:

Dec 11 21:10:30 pytlik ntpd: ntpd startup succeeded
Dec 11 21:10:33 pytlik spamassassin: spamd startup succeeded
Dec 11 21:10:33 pytlik rc: Starting cciss_scsi: succeeded
Dec 11 21:10:33 pytlik gpm: gpm startup succeeded
Dec 11 21:10:37 pytlik hpsmhd: smhstart startup succeeded
Dec 11 21:10:40 pytlik httpd: httpd startup succeeded
Dec 11 21:10:40 pytlik rc: Starting add_scsi_device: succeeded
Dec 11 21:21:50 pytlik cups: cupsd shutdown succeeded
Dec 11 21:21:51 pytlik gpm: gpm shutdown succeeded
Dec 11 21:21:52 pytlik httpd: httpd shutdown succeeded
Dec 11 21:21:52 pytlik spamassassin: spamd shutdown succeeded
Dec 11 21:21:52 pytlik sshd: sshd -TERM succeeded
Dec 11 21:21:52 pytlik named: succeeded
Dec 11 21:21:52 pytlik snmpd: snmpd shutdown succeeded
Dec 11 21:21:52 pytlik xinetd: xinetd shutdown succeeded
Dec 11 21:21:53 pytlik ntpd: ntpd shutdown succeeded

message:

Dec 11 21:10:33 pytlik gpm: gpm startup succeeded
Dec 11 21:10:37 pytlik hpsmhd: smhstart startup succeeded
Dec 11 21:10:40 pytlik httpd: httpd startup succeeded
Dec 11 21:10:40 pytlik rc: Starting add_scsi_device: succeeded
Dec 11 21:14:49 pytlik ntpd[1318]: kernel time discipline status change 41
Dec 11 21:15:54 pytlik ntpd[1318]: kernel time discipline status change 1
Dec 11 21:21:49 pytlik shutdown: shutting down for system reboot
Dec 11 21:21:49 pytlik init: Switching to runlevel: 6
Dec 11 21:21:50 pytlik cups: cupsd shutdown succeeded
Dec 11 21:21:51 pytlik gpm: gpm shutdown succeeded
Dec 11 21:21:52 pytlik httpd: httpd shutdown succeeded

Co zkusit, jako rychlý hotfix, crond v singleuser módu vypnout (chkconfig crond off) a zkusit nabootovat. Jestli se to nezasekne jinde… A po restartu jej znovu spustit, teoreticky by pak mohl být i upovídanější…

Ano, nejlepsi bude zkusit crond vypnout. Ale osobne bych to na cron tedy netypoval. fsck si provedl?

Stydím se, neprovedl, nějak jsem to zazdil, že je tam ten raid. Než tam půjdu, předpokládám, že stále platí pravidlo, že se nesmí spouštět nad přimountovaným oddílem, takže nejprve například:

umout /dev/sda2

fsck /dev/sda2

Nebo mohu využít přepínač na všechny disky -A?

fsck -A

Není možné nějak vynutit fsck přímo při bootu?

Díky.

Děkuji, to vypnutí crond pomohlo, systém se nastartuje, vše běží. Teď už se on samostatný bude řešit za běhu a prý už to tak nespěchá :-). Například, jak vynutit fsck hned po startu. Jen by mě zajímalo, jak to mohl pád napájení způsobit? V každém případě všem moc a moc děkuji.

“Jen by mě zajímalo, jak to mohl pád napájení způsobit?”
Pokud nějaký proces cosi zapisuje na disk, ztráta napájení téměř vždy poruší souborový systém. Můžete se s tím potkat i při ftp spojení pokud je utnete během přenosu mezi dvěma počítači, …

Podle me je nekde ve /var nejaky zamek cronu ci tak neco. cron loguje normalne do messages, ma i volbu na debug mod, takze urcite neni nic ztraceno a da se to vyresit. fsck se na systemch bez systemd dal vyresit jednodusse tim ze se provedlo
touch /.forcefsck

na systemech se systemd (coz by nemel byt pripad centos, ale nejsem si tim 100% jisty), to bohuzel nejde takto jednodusse, ale musi u toho clovek spachat harakiri, protoze autori systemd dosli k zaveru, ze je predsi nesmysl chtit cist z disku na kterem mam provadet fsck soubor .forcefsck, takze vymysleli nejakou obludnost, kterou si nejsem schopen zapamatovat, zato je ve vsech smerech genialni a dokonala… omlouvam se, ale nemohl jsem si pomoci.