On Thu, Dec 11, 2014 at 04:35:24PM +0000, "Jóhann B. Guðmundsson" wrote: > > On 12/11/2014 04:19 PM, Zbigniew Jędrzejewski-Szmek wrote: > >On Thu, Dec 11, 2014 at 04:09:54PM +0000, "Jóhann B. Guðmundsson" wrote: > >>> > >>>On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>>> >The difference is in how the logs are accessed: if journald itself does > >>>> >the jobs, > >>>> >they would be forwarded "live". If anything else, the uploader would be > >>>> >a client > >>>> >which reads the files in/var/log/journal/. The are advantages to both > >>>> >solutions: > >>>> >the first one might be more robust if writing the logs fails or stops > >>>> >for whatever > >>>> >reason. The second one will probably send more logs, because sending of > >>>> >logs can > >>>> >be delayed until the network is up. In the second version, the uploader > >>>> >can also > >>>> >forward logs from other machines (containers). Now that I spelled it > >>>> >out, the second > >>>> >version seems nicer. > >>>> > > >>> > >>>I'm not quite following what you said there but I would actually > >>>think the former as in "forward it live" is better, ju > >Journal carries messages from the initramfs. We cannot send them from > >the initramfs, unless we bring up the network then, which we don't want > >to do just for this purpose. But those messages are stored in /run/log, > >and then flushed to /var/log, and the uploader tool can forward them > >after the network is established. > > > > Right but I thought that might be controlled via socket and once the > network would become available it would dump the content of the > socket buffer on the wire... You need an address to establish a socket. And the socket queue will not be enough if you have copious debug or kernel messages.
Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
