systemd 233

Po čtyřech měsících vývoje od vydání verze 232 (zprávička) oznámil Lennart Poettering vydání verze 233 správce systému a služeb systemd (GitHub, NEWS).

2.3.2017 01:23 | Ladislav Hagara | Nová verze

Komentáře

[Bulánci]

Už fungují?

[Conscript89]

Poslal jsi uz patch?

[Rezza]

Ja jsem kdysi patch poslal :). Ale muj nemergnuli, protoze to byl spis workaround. Pak se toho nekdo chytl a napsal to poradne. Ja bych to udelal, ale chteli i testy proti Widlim a to se me nechtelo...

[saly]

Taky je u vás TAB doplňování minimálně u systemctl děsně pomalý (sekundy)?

[GeorgeWH]

na centos a ubuntu urcite

[belisarivs]

Na openSUSE to jede v pohode.

[Heron]

Bash completion volá něco jako toto ():

time journalctl -F _SYSTEMD_UNIT > /dev/null

real    0m56.254s
user    0m1.544s
sys     0m6.688s

man journalctl

 -F, --field=
           Print all possible data values the specified field can take in all entries of the journal.

Prostě si to nijak neindexuje a při výpisu všech hodnot fieldu to musí udělat full scan kompletních logů (které mohou být komprimované a šifrované - u mě to jede cca 50MB/s).

[xm]

Jak velké logy tam máte? U mě to je "trochu" jiné (zkoušeno na desktopu s btrfs, ne na serveru):

time journalctl -F _SYSTEMD_UNIT > /dev/null

real    0m0,012s
user    0m0,003s
sys     0m0,010s

[Heron]

Celkem malé:

journalctl --disk-usage
Archived and active journals take up 4.1G in the file system.

Opakované volání vypadá takto:

time journalctl -F _SYSTEMD_UNIT > /dev/null

real    0m4.261s

Ale zvykl jsem si

[xm]

No jo no, já mam na desktopu v journald.conf: SystemMaxUse=100M

[Heron]

Něco takového jsem očekával .

To už se to logování může vypnout zcela.

[xm]

Za celá dlouhá léta co používám Linux jsem na desktopu/notebooku nikdy nepotřeboval nějak extra staré logy, cca 2 týdny mi bohatě stačí. Server je ale samozřejmě naprosto jiná situace.

[Michal]

Prostě si to nijak neindexuje a při výpisu všech hodnot fieldu to musí udělat full scan kompletních logů (které mohou být komprimované a šifrované - u mě to jede cca 50MB/s).

Samozrejme, ze sa to indexuje [1].

le64_t field_hash_table_offset; le64_t field_hash_table_size;

Treba ale povedat, ze ten index je "per journal". Myslim, ze problemom je skor "RAM-like disk access pattern", ktory je jednoducho pomaly na rotacnych HDD ([1] predposledny odstavec). Btw, 4GB lokalny log je imho relativne dost :).

[1] https://www.freedesktop.org/wiki/Software/systemd/journal-files/
[2] https://lists.freedesktop.org/archives/systemd-devel/2012-September/006470.html

[xm]

Na Arch Linuxu s btrfs mi jede tab doplňování u systemctl krásně rychle.

[Peter Golis]

Už nie. Keď som na systéme s PATA diskom vymenil 512M RAM za 1024, tak sa to niekoľko krát zrýchlilo. Predtým to dopĺňanie cez bash competition bolo cez 20 sekúnd, teraz menej ako dve. Ale nezdása mi že prechádzanie toho žurnálu s tým súvisí:

$ time journalctl -F _SYSTEMD_UNIT > /dev/null

real    0m0.028s
user    0m0.004s
sys     0m0.016s

[Honz]

Stále kvoká, stále kvoká...

[Agent]

Chocholoušek... Vy nás ale zásobujete, pane Poettering...