Running systemd without systemd-journald
declassed.art
Running systemd without systemd-journald
1–10 of 79 posts
Re: Running systemd without systemd-journald
#2PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO.
You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable, because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem.
TFA is much ado about nothing, learn to measure memory use properly before breaking out the pitch forks.
Full disclosure: I've hacked a bunch on journald upstream.
Re: Running systemd without systemd-journald
#3PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
Memory use has always been a mystery to me and I can easily miss some things. Thanks for pointing to. Anyway, the right solution for me is tldr, all the rest is shit.
Re: Running systemd without systemd-journald
#4PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
I was wondering about this exact thing when the article didn't break down the ram usage. Thanks!
Re: Running systemd without systemd-journald
#5PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap.
You can run quite a lot in 512MB of RAM if you use the right languages to write code in. I was surprised about how little RAM my moderately complex daemon written in Rust uses, for example; I expected to have to allocate a gigabyte of RAM to the VM running it (based on what other tools similar to what I was doing needed) but the entire system turned out to be quite comfortable with just a quarter of that. I didn't even try to optimise for memory usage, which is what made this so surprising. I stil had to give it some more RAM because unattended upgrades tended to get stuck, but I learned a lesson that day.
Ever since I've been meaning to try to mess with Firecracker + bare bones daemons to run virtual machines services with absolutely minimal overhead. I like the virtualisation boundaries from a security standpoint much more than container boundaries and now I wonder how much I can shrink my overhead by.
Re: Running systemd without systemd-journald
#6PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap. You can run quite a lot in 512MB of RAM if you use the right languages to w…
If you're concerned about storage wear you'd just run journald without /var/log/journal so it's volatile (tmpfs) only. At least that way you still have journals for your current boot and functionality like `systemctl status $service` can still tell you some journal information.
Re: Running systemd without systemd-journald
#7Earlier quoted context omitted.
This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap. You can run quite a lot in 512MB of RAM if you use the right languages to w…
If you're concerned about storage wear you'd just run journald without /var/log/journal so it's volatile (tmpfs) only. At least that way you still have journals for your current boot and functionality like `systemctl status $service` can still tell you some journal information.
Yeah this is a lot of work to avoid reading journald.conf, switching the storage to volatile, and capping the memory usage to whatever you want.
Re: Running systemd without systemd-journald
#8PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap. You can run quite a lot in 512MB of RAM if you use the right languages to w…
> This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap.
Well the author seems to want text logs instead, which seems much much worse for this.
Re: Running systemd without systemd-journald
#9I have but one word for this guy.
Devuan
I see no reason not to consider it.
He is a Debian user who hates the way systemd works.
Devuan is for you.
Re: Running systemd without systemd-journald
#10PSA: systemd-journald uses shared file-backed mappings via mmap() for its journal IO. You must subtract its shared memory use from its resident memory use before judging how much memory it's consuming. The file-backed shared mappings are reclaimable , because they are file-backed. The kernel will just evict the mapped journal pages at will, since they can always be faulted back in from the filesystem. TFA is much ado…
This is true, but the author seems to be running their services on several Raspberry Pi like devices whose flash storage may be unstable or quick to wear out. Eliminating unnecessary writes and swap space (depending on the application), those megabytes of extra memory may be just enough what tricks the system into committing memory into swap. You can run quite a lot in 512MB of RAM if you use the right languages to w…
>You can run quite a lot in 512MB of RAM if you use the right languages to write code in.
I recently delivered a production-ready embedded system running Armbian with 512megs RAM, and indeed disabled systemd-journald for our uses, also .. but even with it enabled, our Lua-based app was (science/data analysis on sensor network) running in the best environment it has ever run, so I can confirm: 512MB is enough for a lot of things.