Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running systemd without systemd-journald

declassed.art

Post reply on HN
Print view View original

11–20 of 79 posts

Re: Running systemd without systemd-journald

#11

Post by seclorum_wien »

frankharv wrote: post #9

I 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 ..

Re: Running systemd without systemd-journald

#14

Post by saurik »

Would doing something like this work around the "journald drops the most important error messages" issue that has been known/outstanding for ten years (bug moved to GitHub six years ago), or is that more of a fundamental design mistake in systemd itself?

https://github.com/systemd/systemd/issues/2913

https://bugs.freedesktop.org/show_bug.cgi?id=50184

Re: Running systemd without systemd-journald

#15

Post by hedora »

pengaru wrote: post #2

PSA: 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…

Did the Linux kernel ever fix the thing where it evicts code pages at the same priority as files mapped read/write?

I haven't checked in the last 4 years or so, but, before that, every time I've worked with a Linux-based storage system that used mmap to write to files, I've ended up rewriting it to use pread/pwrite.

Each time, there was no perceptible CPU hit, but there was a massive page cache / memory pressure win. It turns out that aggressively evicting warm code pages then faulting them back in is bad for system performance, even with a fast SSD.

Re: Running systemd without systemd-journald

#17

Post by TacticalCoder »

frankharv wrote: post #9

I 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.

It depends what you're doing but for my "workstation", Devuan is indeed working flawlessly. I'm running it since six months or so on my main PC (a little Ryzen 3700X / 32 GB or RAM) and I'm very happy with it.

Now if you're a sysadmin and have come to rely on systemd and are now locked in, Devuan is obviously not for you. But if you're running Linux on a desktop or on a laptop and aren't a fan of systemd, Devuan is great.

Re: Running systemd without systemd-journald

#18

Post by dark-star »

frankharv wrote: post #9

I 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.

He doesn't even know how to read man pages (journald.conf(5) describes the setup he is looking for), and he doesn't know how memory usage on Linux works (shared /mmap()ed memory is counted for each process). Do you really think his issues go away when he switches to Devuan? He'll probably just yell at different clouds

Other than that, Devuan is a solid choice for people who want to get rid of systemd. It comes with the Debian-typical rather old versions of most programs, but I guess for a file server it doesn't matter much if you run kernel 4.19 or 5.15

Re: Running systemd without systemd-journald

#19

Post by frankjr »

saurik wrote: post #14

Would doing something like this work around the "journald drops the most important error messages" issue that has been known/outstanding for ten years (bug moved to GitHub six years ago), or is that more of a fundamental design mistake in systemd itself? https://github.com/systemd/systemd/issues/2913 https://bugs.freedesktop.org/show_bug.cgi?id=50184

It's not accurate to say it "drops" error messages. The bug causes these messages to not be attributed to a particular unit - you can still see them with `journalctl` but not with `journalctl -u foo`. Still pretty annoying and should absolutely be fixed (although I'm not sure if systemd is the right place to do it).
Post reply on HN