Rsyslogd přestal logovat hostname

17.6.2016 18:01 | Debian | poslední úprava: 13.6.2016 07:49

Používat Linux je jako žít v domě plném architektů, z nichž jeden je Lennart P. O co jde ? V Debianu Jessie po upgradu přestal syslogd psát:

Jun 13 07:34:57 hostname message

ale místo toho

Jun 13 07:34:57 172.16.22.33 message

Nechápal jsem proč, prolezl systém až jsem skončil na gůglu, který našel vysvětlení, které znamená: Pokud vám rsyslogd neukládá hostname, připište si do /etc/rsyslog.conf $PreserveFQDN on. Na kecy o rebootu samozřejmě zapomeňte a otočte jen rsyslog - pak vše funguje jako dřív.        

Komentáře

[tough guy]

To nič nieje - predstav si že nainštaluješ systém na kryptovanu partíciu, pripojíš ďalší disk, inicializuješ partíciu, nastavíš na automount cez keyfile v crypttab a fstab a zabudneš naformatovať - systemd pri štarte začne pripájať - neide mu to a BEZ LIMITU pripája ďalej a nepusti dalej v bootovani. Nepomôže nič len nabootovať live a sformatovať predmetný kryptovaný disk... Otras...

[pavele]

Hm, řekl bych, že jsem měl stejný problém s bootováním po tom, co se mi zřejmě "nabořil" samostatný, extra vytvořený diskový oddíl s btrfs. Měl se připojit taky přes fstab. Asi nějaká feature...

[Bedňa]

On systemd skončil v no time limit loop aj s pripojeným telefónom, nerobím si nádeje že by to opravili.

[pavele]

To děláš správně... Našel jsem spoustu informací o této "feature" (rok 2012) nyní na Debian Jessie, tak ostatních distribucích.

Skutečně se jedná o "feature", /etc/fstab se má doplnit o volby "nofail,x-systemd.device-timeout=1". Pak by to teroteticky mělo najet, ale bez jakýchkoliv chybových zpráv v logu.

Pokrok se nedá zastavit...

[Jendа]

Ano, preventivně teď píšu do všech fstabů nofail, protože ten dement dokáže nenajet (do stavu abych se tam dokázal naSSHčkovat a opravit to), když nepřipojí /mnt/nevýzamný-adresář.

[martin]

tjn, chtit po lidech, aby meli korektni nastaveni, to je totalni otres! co prijde priste?

[pavlix]

Příště bychom třeba mohli chtít takový nesmysl, jako aby vývojáři software trochu přemýšleli o jeho použití. A především o tom, že zablokovat konzoli a vynutit si čekání i kdyby na desítky vteřin působí asi podobně jako když dobíháte MHD a řidič vám zavře dveře před nosem. I když hádám, že oni tohle všechno dobře vědí a velmi dobře se baví, stejně jako ti řidiči. :D

[lenny]

Nechcem sa do nikoho navazat ale podla mna je to nasa chyba! kebyze ty linuxaci ktory mozu nieco zmenit a su pritom proti featuram ako system d sa ozvali a zacali pretlacat napr OpenRC teda nie ze ponukli alternativu ale tiez bez hlavo zacali pretlacat tak by to bolo o niecom inom

realne k systemd su tieto alternativy 1. ziadna zmena - slackware, XRUX a podobne, bez zmeny je aj Devuan a pod. alebo distra ktore uz maju nahradu ale topia sa s problemom ako dalej kedze GNOME HELL je zavisle na systemd. takze je tu RUNIT a OPENRC ja som za OPENRC co tak pretlacat silou - vyssou mocou OpenRC ktore je tiez v C, ale nie je take na hlavu ako sysd a neriesi init a podobne veci?

[Georgius]

Já jsem molochy typu Gnome a KDE odepsal, střídám lxde a icewm . Ale zrovna dneska mi na noťasu přestalo fungovat do té doby (od roku 2009 ?) bezchybné uspávání (po zaklopení víka neusne, při pm-suspend se hryzne - zůstane zapnutý a bliká capslok+numlok). Tuším, kdo za to může. GRRRR.

[Bedňa]

Tak máme tu distro bez systemd s IceWM

[Georgius]

teď, když už konečně začal fungovat nm-applet a dokonce ani nepadá při zapnutí VPN ?

[Bedňa]

To je osud NM tiež bude, ale ešte sa zďaleka nevie kedy.

[Josef Kufner]

zůstane zapnutý a bliká capslok+numlok

To je v jádře, za to systemd nemůže. Přepni se před uspáním do konzole, ono ti to řekne, co a jak. Možná. A nebo prostě jen použij starší jádro.

[Georgius]

tak jsem se na to ještě jednou podíval a noťas má jinak diodky - pochopitelně je to numloc+scroll lock neboli kernel panic. Tak jsem s tím včera zabil několik hodin a zjistil jsem, že ať už dám suspend to ram jakkoliv (pm-suspend, s2ram, zápis "mem" do /sys/power state) systém správně usne a něco o tom napíše do logů. O vteřinu či dvě později se ale probudí a dříve než rozsvítí display, zpanikaří jádro. O této "probouzecí fázi" není v logách ani nic. Koukal jsem, že asi nejsem sám, tady jsem se dočetl různé chytré rady, které mi ale v případě, kdy noťas pochopitelně už nemá sériák a jádro zpanikaří před naběhnutím rafiky je platný jak mrtvýmu zimník. Chová se to stejně s libovolným jádrem 3.x-4.6 ... Jo a je so Stretch amd64. Jo a pro úplnost, kernel panic jsem na tomle stroji (r.v. 2009) nikdy neviděl a to ho provozuju od Ubuntu 9.10 (někdy po příchodu Unity jsem přešel na Debian a skončil u současného testingu) - s uspáváním nikdy nebyl problém. Já bych si asi i koupil support, ale zkušenosti s Canonicalem mne od toho nadlouho odradily (vždycky to skončilo tak, že mi ruply nervy, dal jsem tomu jeden den z víkendu, vyřešil si to sám a napsal jim, co mi měli poradit). A tomu, kdo rozbije něco, o čem sedm let "nevím" bych nakopal ...

Flame: na kterou odrůdu BSD je nejlepší přejít ? (třeba to BSD co prodává Apple nevypadá špatně, akorát ta cena HW ...)

[Heron]

Zažil jsem situaci, kdy po bootu nenajel mdadm raid (chybou hw). SystemD čekal (sice s default timeout 90s) na device , aby mohl připojit fs. Nedočkal se (protože mdadm to pole odmítl sestavit, tak nevím, na co systemd čekal), zbytek služeb po chvíli nastartoval. Fajn. To lze akceptovat.

Mno ale co se nestalo. Když jsem ručně opravil pole (no opravil, force assembly), tak se systemd okamžitě pokusil fs připojit jako readwrite. Což je geniální nápad v případě potenciálně rozbitého pole. Jako admin jsem si pochopitelně chtěl mount fs řídit sám, ale systemd měl někde ve frontě čekající úlohu namountovat fs, až se device objeví. Výsledkem bylo, že se driver fs během mountu ten fs pokusil opravit (takže nastal write a další pokusy o rozhození toho pole byly v tahu - samozřejmě, zálohy by se vytáhly tak jako tak, o ta data nešlo, šlo jen o pokus o opravu).

[little.owl]

Fajn. To lze akceptovat.

Akceptovat? A co byste delal jineho? Sestavoval degradovane pole automaticky?

Když jsem ručně opravil pole (no opravil, force assembly), tak se systemd okamžitě pokusil fs připojit jako readwrite.

V jakem modu jste to opravoval? Mel jste nejakou mount unit ci automount unit?

Vasim prispevkem jste me rozhoupal konecne opravit RAID5 na CentOS 7 (diky ), kde by jeden disk vadny. Vymenil jsem disk, presel do emergency modu, kdy se pouze pripojil root jako read-only a zadny jiny souborovy system, opravil pole, presel do default modu, zadny problem.

[Heron]

Akceptovat? A co byste delal jineho? Sestavoval degradovane pole automaticky?

Ne, lze akceptovat ten timeout. (Navíc, degradované pole se běžně sestaví a běží - toto ovšem nebyl tento případ a to pole se sestavit nemělo a správně nesestavilo.) I když bych byl mnohem raději, kdyby nečekal a přímo to hodil do rescue režimu (to, že se pole nedá sestavit ví mdadm okamžitě). Takhle jen počkal na timeout a startoval vesele dál s jednou unitou failed (sys-cosi.device).

V jakem modu jste to opravoval? Mel jste nejakou mount unit ci automount unit?

Nevím. Je to Debian Testing. Během normálního bootu, kdy se nenastartoval hw řadič a mdadm chyběly dva disky. Systemd čekal na zařízení, a potom (po timeout) normálně pokračoval běžný boot.

Po bootu jsem zjistil, že tomu chybí dva disky, řadič jsem resetnul a pokusil jsem se (ze sportu - zálohy by se vytáhly v každém případě) o assembly. Tentokrát už se všemi disky. S force se to podařilo (jak jinak). Ovšem nečekal jsem, že systemd okamžitě začne připojovat fs, který se mu nepodařilo připojit během bootu. FS je definovaný v fstabu.

Vymenil jsem disk, presel do emergency modu

Nevidím jediný důvod, proč pro výměnu disku v raid5 jít do emergency. Pole běží dál v degradovaném režimu, data jsou v pořádku. Disk se dá připojit kdykoliv za běhu (na strojích s hotswapem celá výměna může proběhnout kompletně za běhu).

V mém případě byl ten problém, že systemd se okamžitě pokusit připojit fs jakmile se ten block device objevil. Toto je opět zcela nové chování, takto se žádná distribuce nikdy nechovala (fs definované ve fstabu se připojovaly jen během bootu a pokud se to nepodařilo, tak se boot zpravidla přerušil a rc systém přešel do rescue režimu.)

[little.owl]

Ovšem nečekal jsem, že systemd okamžitě začne připojovat fs, který se mu nepodařilo připojit během bootu. FS je definovaný v fstabu.

Tohle me prave take prekvapuje. Zalezi na parametrech v fstab, podle nichz systemd generuje mount/automount unity.

Nevidím jediný důvod, proč pro výměnu disku v raid5 jít do emergency. Pole běží dál v degradovaném režimu, data jsou v pořádku.

Nechtel jsem riskovat kdyz nerozumim predchozimu chovani, emergency mod by mel byt bezpecny - tohle byl muj zalozni server a zalohy zaloh nemam .

[Jendа]

Akceptovat? A co byste delal jineho?

Implementoval bych, že stisknutí ^C na konzoli zruší aktuálně čekající službu.

V jakem modu jste to opravoval? Mel jste nejakou mount unit ci automount unit?

Bugreport něčeho podobného.

[little.owl]

Implementoval bych, že stisknutí ^C na konzoli zruší aktuálně čekající službu.

U parallelniho startu rizeneho zavislostmi tech aktualne cekajicich sluzeb muze byt plno.

Bugreport něčeho podobného.

To vypada, ze po selhani fsck nektera debianni unita remountovalo root jako rw. Na CentOS to je v emergency modu root ro.

[R]

Po akom upgrade to prestalo fungovat? Mam par instalacii Jessie a nikde som sa s tym nestretol. Ale vsetky su bez systemd.

[little.owl]

Nekoncici story se rsyslog a FQDN (zde, zde ci zde). Nastesti systemd-journal-remote zacina byt pomalu pouzitelny.

[pavlix]

Je to prostě inovátor. Přijde a obrátí vám celý dům vzhůru nohama.

[little.owl]

To jako takhle?