>>> >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...
I was thinking about the same, but what about the size Limitation? Is there not a long standing issue that the socket buffer size is global and not per socket? I remember a discussion around one of the plumbers conference? Anyway what abut a two fold approach? the journal learns plain live forwarding to a remote host or even broadcast. and the messages can be forwarded once the network is available. If socket controlled works you may win a few more messages but you never know you get all messages from boot. This is current behavior of remote syslog forwarding I assume. If you want more there could be a independent tool works like the systems-journal-gatewayd or systemd-journal-uplaod and can be started later once network available. This will read the log and forward all messages from the current boot and following. Holger -- Holger Winkelmann email: [email protected] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
