On Mo, 04.09.23 16:35, Etienne Doms (etienne.doms@xxxxxxxxx) wrote: > Hi, > > I have some embedded systems in the wild, not connected to anything, > on which you can push a button "something went wrong, create a dump". > Then later I can fetch the said dump and inspect it. > > I'd like to include the whole journal, for the current boot, in a > binary format so that I can later do "journalctl --file > path/to/journal-dump.bin" from another machine. I understand that > internally everything is stored in /var/log/journal/<machine-id>, but > I guess that I cannot blindly tar/cp the .journal files, since this > would be racy. That should actually work fine. journald has no locking around journal files: the server that writes to the files and the client that reads them are not synchronized. The client is supposed to handle incomplete writes by simply suppressing display of the trailing, incomplete entries. This is a common code path, that is quite well tested these days. Hence, I should actually be fine to just copy the journal files as they are being written, the tools on the other side will possibly then see a file with records currently "in flight" that are referenced at some places but not others, but that should be totally OK, the tools should handle this, and this i no different from their local access. > So, is there an API to safely dump a big ".journal" file containing a > snapshot of "journalctl -b"? I could not find anything in the > documentation, sorry in advance if I missed something obvious. You can use "-o export" to dumb the files in an "export" format. But this is just about returning the data in a different format, it does not give you any synchronization guarantess since journalctl started that way will just read the data from the journal files unsynchronized as everyeone else too. Lennart -- Lennart Poettering, Berlin