ZeroUno ha scritto:syslogd morirà quando l'occhio umano sarà in grado di leggere i file binari di journald senza tool diversi da more e grep.
Nel confronto tra linux e windows quello che è sempre risaltato sono i file di configurazione e log in formato testuale consultabili con vi contro il registro di configurazione consultabile con regedit e i log da apposita interfaccia.
Guarda, sui log binari non sono convinto nemmeno io. Su systemd in sé ho cambiato idea da un po' e l'ho rivalutato parecchio, ma i log binari sono ancora una cosa che non mi piace.
Tuttavia, journald in sé non è necessariamente un male.
Ha dei concetti interessanti dietro, tipo quello di gestire tutti i log e di serializzarli allo stesso modo, eliminando così la necessità di creare parser esclusivi per ogni log.
Inoltre riduce anche la dipendenza dalle regex da parte dei sysadmin, in quanto permette direttamente con i suoi parametri di restringere l'output ad una determinata unit* e ad una determinata fascia oraria (--since=<data> --until=<data>). Permette inoltre di serializzarlo in formati differenti, tipo JSON.
I primi sono consultabili anche se l'host non fa il boot. I secondi beh, auguri se la macchina non sale.
Spero di non arrivare ad equipararli.
Oddio, non mi è mai capitata una situazione di questo tipo, quindi non posso risponderti.
Però, hai provato a lanciare dall'host "journalctl --root=/path/della/root ..."?
Stando al man di journalctl dice:
--root=ROOT
Takes a directory path as an argument. If specified, journalctl will operate on catalog file hierarchy underneath the specified directory instead of the root directory (e.g. --update-catalog will create ROOT/var/lib/systemd/catalog/database).
Onestamente, considerando che systemd è stato sponsorizzato come una soluzione soprattutto lato server, sarebbe ridicolo se non riuscisse a fare una cosa simile.
EDIT: Il parametro non è --root, ma -D, come dice il
wiki di ArchLinux
Certo, farlo da macchine non Linux diventa un problema. Ma onestamente: quanti casi esistono di montaggio di file system Linux da host non Linux?
Windows non lo supporta di sicuro e gli altri UNIX idem, specie se si fa uso di file system moderni come Btrfs.
Di base l'uso del logging binario è semplicemente un cercare di aggirare la lentezza di grep e awk su grossi log.
Ma il problema è sempre lo stesso: si corrompono.
Certo, la corruzione di un log non lo rende necessariamente illeggibile, dato che è comunque consultabile eccetto per la riga che stava venendo scritta al momento del crash, tuttavia rimane il fatto che un log plain-text è più affidabile in quanto fa uso di un set di caratteri più ristretto.
Io, sinceramente, avrei implementato il tutto diversamente, con una chiave apposita all'interno di /etc/systemd/journald.conf, nella quale specificare il tipo di output: binario o plain-text, e specificando nella documentazione che si sarebbe potuto scegliere sulla base delle proprie necessità (affidabilità vs prestazioni) il tipo di formato da usare.
In questa maniera avremmo potuto evitare di mettere il redirect su syslogd, che è una soluzione ridicola, e avremmo potuto sfruttare direttamente tutte le capacità di journald anche su log plain-text.
Ma come ho già detto, è stata una mossa voluta. E questo è uno dei suoi punti negativi.
Launchd me lo devo vedere perché ho un applicazione che lo usa, anche se credo che usi una reimplementazione customizzata.
Launchd è il gestore dei servizi di Mac OS X ed è praticamente come SMF: manifest in XML. Più precisamente: formato
PLIST, che è un XML ancora più verboso nel normale.
*unit: in systemd ogni cosa è una unit.
È molto simile al concetto di UNIX: tutto è un file, ma con la differenza che le unit sono file INI consultabili e sono soggetti al controllo di systemd, quindi possono essere soggetti al respawn in caso di caduta, avere dei limiti imposti dai cgroup ecc.
Una unit può essere un servizio, un timer (un'operazione pianificata. Il nostro cron, per farla breve), un mount-point, un target, una swap, un socket ecc.