No post body was provided.
Running systemd without systemd-journald
31–40 of 79 posts
Re: Running systemd without systemd-journald
#32Quoted post unavailable.
[deleted]
Re: Running systemd without systemd-journald
#33I 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.
if you run a Debian-based production server, then Devuan is for you.
Devuan can allow your precious daemon to stay up despite netdev going offline, unlike systemd-networkd which would kill the daemon.
This is quite important if your large ling-running daemon has statefulness data.
Re: Running systemd without systemd-journald
#34PSA: 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!
I was waiting for the author to check the memory usage of rsyslog and becoming enlightened... but it didn't happen. Reminder: check your assumptions/result after changes. He could learn that rsyslog uses way more shared memory than journald (>900M on my system) and it doesn't matter.
Re: Running systemd without systemd-journald
#35I 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.
Three cheers for Devuan! :). Completely agree, this would've been an easy distro switch-a-rooni ..
I switched all my Debian to Devuan. Havent looked back.
Re: Running systemd without systemd-journald
#36Earlier quoted context omitted.
> systemd is incredibly useful and powerful. In that one sentence I think you've highlighted what garners hate from the haters. It's powerful, and it's great when that power is used for good. Those times when it's not is where people get agitated.
Do you have an example of when systemd is not used for good?
it kills production daemons having long running stateful data whenever the netdev goes offline., systemd-networkd, that is.
Re: Running systemd without systemd-journald
#37PSA: 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…
It's not quite that simple: while clean file-backed pages are cheaper than, say, private dirty pages (which the kernel must preserve as long as anyone references them), they're not free : you're still paying an opportunity cost. That is, the kernel is, at least for a time, keeping each clean file-backed page resident when it could be keeping some other page, perhaps a more useful one, in RAM instead. If systemd-journ…
> the kernel is, at least for a time, keeping each clean file-backed page resident when it could be keeping some other page
It's almost the same result for the standard page cache when you're reading a file, isn't it?
Re: Running systemd without systemd-journald
#38Earlier 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…
>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 lo…
Windows 95 ran an entire OS with decent UI in 8 MB of RAM. One really has to wonder, where is all the RAM going these days? I think the knowledge of doing anything with only 8 MB of RAM has gone away, we don't know how to do it anymore.
Re: Running systemd without systemd-journald
#39Weird; the systemd journal is the feature I want most! It would be the last thing I would ever consider disabling.
I don't know if this is still an issue but the last time I used journald the logs would occasionally become corrupted and journalctl would refuse to read them. The fix was to just delete the logs. I have no idea how logging got so screwed up that corruption in part of the file could make the rest of the log file unreadable. I mean, it's a journal, it's right in the name. Ever since then I switched to rsyslogd and the…
Keep in mind that rsyslog doesn't even attempt to verify logs. An alternative explanation is: my system is corrupting logs, I changed to a logging daemon which doesn't tell me about it.
I mean, there could definitely be a bug in journald, but I haven't seen any fixes mentioned in changelog for the last 5 years and if it was happening in standard usage, people would notice.
For recovering corrupted logs - you can still "less" them as usual. They have some extra markers, but the text is available as text. Journalctl has some special options for that too.
Re: Running systemd without systemd-journald
#40Earlier quoted context omitted.
>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 lo…
Windows 95 ran an entire OS with decent UI in 8 MB of RAM. One really has to wonder, where is all the RAM going these days? I think the knowledge of doing anything with only 8 MB of RAM has gone away, we don't know how to do it anymore.
It's not the knowledge - it's the increased complexity of the entire stack, all the way down to the hardware. A modern linux kernel image is easily bigger than 8MB, and that needs to be in memory at all times. Why? Because of all the functionality it has these days, to fit all the possible usecases people need. Windows 95 didn't have Swap, didn't support many filesystems, didn't have central logging, didn't have ASLR, let alone support for containers, and many other features I'm forgetting along the way.
Sure you could strip away a lot of that functionality, even at the distribution level (by for example not using an init system at all, instead just one shell script to initialize things), but then you'd end up with an operating system that's not general purpose for today's standards anymore.