Re: [systemd-devel] state of journal-upload and journal-remote?
On 20-12-19 13:28:45, Lennart Poettering wrote: On So, 22.11.20 11:34, Florian Klink (flo...@flokli.de) wrote: Hey, I'm wondering about the current state of journal-upload and journal-remote. Traffic on this list about it has gotten pretty silent, there has been bug reports opened in 2018 about this being somewhat broken: https://github.com/systemd/systemd/issues/9858 (and search for other issues). All in all this seems somewhat buggy, underdocumented, and given most people do log forwarding these days by running some other daemons, specific to their environment, which query the journal for logs and forward them on their own, without using any of the journal-upload/journal-remote stuff… Is there anyone actually using this? Would it make sense to deprecate and eventually remove it alltogether? I think some of the components involved are used, others are not. It could certainly use some love to make it round again though. It's too good to remove I'd say. The HTTP/openssl bits, too? I'd rather see the thing fixed (work on that would be minor I guess), and a test added so that it doesn't regress again. We'd certainly need some more docs on the HTTP bits, and wire this into CI to ensure it keeps working. As written in 20201122174743.3c4pc64wl5dnf...@ws.flokli.de, I'd be more in favour of a `journalctl [--receive]` reading from stdin, and removing all the networked stuff entirely. -- Florian Klink ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] state of journal-upload and journal-remote?
On 20-11-22 16:25:29, Mantas Mikulėnas wrote: I'm wondering about the current state of journal-upload and journal-remote. I'm less sure about the HTTP bits, but I think journal-remote can be useful on its own, as it also takes input from stdin (doing the opposite of `journalctl -o export`)... So what about moving this logic to a journalctl [--receive] parameter, which reads such a format from stdin? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] state of journal-upload and journal-remote?
Hey, I'm wondering about the current state of journal-upload and journal-remote. Traffic on this list about it has gotten pretty silent, there has been bug reports opened in 2018 about this being somewhat broken: https://github.com/systemd/systemd/issues/9858 (and search for other issues). All in all this seems somewhat buggy, underdocumented, and given most people do log forwarding these days by running some other daemons, specific to their environment, which query the journal for logs and forward them on their own, without using any of the journal-upload/journal-remote stuff… Is there anyone actually using this? Would it make sense to deprecate and eventually remove it alltogether? Regards, flokli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd remounts root fs read-only, doesn't detect lxc-libvirt
Am 29.09.2013 22:06, schrieb Florian Klink: Am 29.09.2013 21:59, schrieb Lennart Poettering: On Sat, 28.09.13 16:35, Florian Klink (flo...@flokli.de) wrote: Hi, I setup some freshly-bootstrapped Arch Linux containers using systemd 204 (so only systemd inside, no old init systems) They are started using libvirt-lxc. The root of the container filesystem is a mountpoint (in my case, aufs filesystem, to save some space and use base images, but this is also reproducible with a loop ext filesystem mounted on the root location). /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 rw,relatime,data=ordered 0 0 According to src/core/umount.c, the remount,ro of / should not occur when systemd is started inside a container environment. However, after starting up, then shutting down the container, the filesystem is mounted ro. /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 ro,relatime,data=ordered 0 0 So probably systemd is not detecting here correctly that it's running inside the container, although lxc-libvirt as env for pid 1 seems to be supported inside detect_container(). So something is apparently wrong here. Is there any way to find out why it is remounting ro? Maybe you have listed it as such in the fstab of the container? Does systemd-detect-virt in the container detect libvirt-lxc correcty? Lennart yes, it says libvirt-lxc. fstab inside the container is empty. Florian I did the bootstrap of the container fs again, now systemd-207-5 is installed. With this, the problem magically disappears, container fs stays mounted rw. But still thanks for your help! Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd remounts root fs read-only, doesn't detect lxc-libvirt
Am 29.09.2013 21:59, schrieb Lennart Poettering: On Sat, 28.09.13 16:35, Florian Klink (flo...@flokli.de) wrote: Hi, I setup some freshly-bootstrapped Arch Linux containers using systemd 204 (so only systemd inside, no old init systems) They are started using libvirt-lxc. The root of the container filesystem is a mountpoint (in my case, aufs filesystem, to save some space and use base images, but this is also reproducible with a loop ext filesystem mounted on the root location). /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 rw,relatime,data=ordered 0 0 According to src/core/umount.c, the remount,ro of / should not occur when systemd is started inside a container environment. However, after starting up, then shutting down the container, the filesystem is mounted ro. /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 ro,relatime,data=ordered 0 0 So probably systemd is not detecting here correctly that it's running inside the container, although lxc-libvirt as env for pid 1 seems to be supported inside detect_container(). So something is apparently wrong here. Is there any way to find out why it is remounting ro? Maybe you have listed it as such in the fstab of the container? Does systemd-detect-virt in the container detect libvirt-lxc correcty? Lennart yes, it says libvirt-lxc. fstab inside the container is empty. Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd remounts root fs read-only, doesn't detect lxc-libvirt
Hi, I setup some freshly-bootstrapped Arch Linux containers using systemd 204 (so only systemd inside, no old init systems) They are started using libvirt-lxc. The root of the container filesystem is a mountpoint (in my case, aufs filesystem, to save some space and use base images, but this is also reproducible with a loop ext filesystem mounted on the root location). /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 rw,relatime,data=ordered 0 0 According to src/core/umount.c, the remount,ro of / should not occur when systemd is started inside a container environment. However, after starting up, then shutting down the container, the filesystem is mounted ro. /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 ro,relatime,data=ordered 0 0 So probably systemd is not detecting here correctly that it's running inside the container, although lxc-libvirt as env for pid 1 seems to be supported inside detect_container(). So something is apparently wrong here. Is there any way to find out why it is remounting ro? Regards, Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
