Although it is true that syslog can be set up to send logs to other machines, there are use cases with systemd-journal-* that are not easily achievable by syslog alone.
For one, syslog does not by itself guarantee delivery of messages. The rsyslog-relp package can provide this but it is a separate package and hence does not strictly qualify as trivial, plus the configuration to reliably transmit messages even when the syslog client-server connection is not working is not documented except on the rsyslog website. With systemd-journal-upload, the --save-state=/some/file flags on clients together with systemd-journal-remote --listen on a server will guarantee the delivery of any journal entries that have not been uploaded before. That is a lot more trivial than configuring rsyslog-relp. Secondly, the feature set of systemd-journal-gatewayd is unique in that it allows for remote clients to connect to a running machine and retrieve or listen for events from its journal, such as core dumps. Such functionality is simply unavailable with just syslog. It in fact allows remote journal viewing without a running server to which the journal is being sent. Even if its maturity is unknown, it is a maintained feature and was mentioned at FOSDEM 2015. By not packaging it, users aren't able to use it and there won't be any reports on its use at all. Though admittedly the dependancy on libmicrohttpd is not ideal, rsyslog-relp is a separate package from rsyslog as well so it would not seem unreasonable to add the set of systemd-journal-gatewayd|upload|remote tools as a separately available package. -- Regards. Gerben Meijer Day by Day -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
