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

21–30 of 79 posts

Re: Running systemd without systemd-journald

#21

Post by iforgotpassword »

axy wrote: post #3
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…

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.

Yeah, the rest just shows that op likes to do things like they've always done it. How you can prefer to poke around syslog and ps output to determine the state of a service instead if just doing systemctl status is beyond me for example.

Re: Running systemd without systemd-journald

#22

Post by quotemstr »

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…

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-journald is append-mostly, it'd be useful to MADV_FREE (after msync) any pages behind the current write pointer so as to give the kernel a hint that it can get rid of those clean file-backed pages early. I'd actually suggest getting rid of the use of memory mapping entirely, but doing so would likely be a bigger ask.

Re: Running systemd without systemd-journald

#23

Post by andrewstuart »

systemd is incredibly useful and powerful.

If you are a developer on Linux then you really owe it to yourself to learn as much as you can about systemd.

If you really understand systemd then you'll find yourself architecting your software around its capabilities.

systemd, if you understand it, can mean you can completely avoid large chunks of development you might otherwise have assumed you need to do.

socket activated services, nspawn, traffic accounting, the list of juicy goodness goes on and on....

Ignore the haters, they wouldn't hate if they dedicated their energy to understanding systemd instead of hating on it.

In 2022 you are a really an incomplete full stack developer if systemd is not one of the technologies you know very well.

Re: Running systemd without systemd-journald

#24

Post by jcalvinowens »

hedora wrote: post #15
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.…

There's nothing to "fix" here, in some cases what you want is not optimal. It is perfectly reasonable for the kernel to prioritize data pages you touched more recently than code pages by default. It's essentially a big LRU, always has been.

If you don't like that, you can always use mlock(). You can also tune things like writeback sysctls and readahead behavior. But I disagree it's "broken" because it doesn't do what you want by default.

Re: Running systemd without systemd-journald

#25

Post by coredog64 »

andrewstuart wrote: post #23

systemd is incredibly useful and powerful. If you are a developer on Linux then you really owe it to yourself to learn as much as you can about systemd. If you really understand systemd then you'll find yourself architecting your software around its capabilities. systemd, if you understand it, can mean you can completely avoid large chunks of development you might otherwise have assumed you need to do. socket activat…

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

Re: Running systemd without systemd-journald

#26

Post by qbasic_forever »

coredog64 wrote: post #25
andrewstuart wrote: post #23

systemd is incredibly useful and powerful. If you are a developer on Linux then you really owe it to yourself to learn as much as you can about systemd. If you really understand systemd then you'll find yourself architecting your software around its capabilities. systemd, if you understand it, can mean you can completely avoid large chunks of development you might otherwise have assumed you need to do. socket activat…

> 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?

Re: Running systemd without systemd-journald

#27

Post by heretogetout »

db48x wrote: post #12

Weird; 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 like. Rock solid.

Re: Running systemd without systemd-journald

#28

Post by [deleted] »

coredog64 wrote: post #25
andrewstuart wrote: post #23

systemd is incredibly useful and powerful. If you are a developer on Linux then you really owe it to yourself to learn as much as you can about systemd. If you really understand systemd then you'll find yourself architecting your software around its capabilities. systemd, if you understand it, can mean you can completely avoid large chunks of development you might otherwise have assumed you need to do. socket activat…

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

[deleted]

Re: Running systemd without systemd-journald

#29

Post by Arch-TK »

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.

I recently got a new work laptop and decided to take the opportunity to switch from using windows 10 with a linux VM (please don't try to sell me WSL2, I'm not interested) to plain linux. I decided to pick devuan stable since the base machine needs to be... stable. I have no interest in using systemd on anything which needs to be stable. I feel happy for anyone who has never encountered severe stability issues with systemd but I am not that person. Devuan comes with sysvinit which is also trash but it offers the opportunity to use other inits. At this point in time I have switched it from sysvinit to runit and eventually ripped out the entire runit infrastructure that comes with devuan and replaced it with something heavily inspired by void's runit. This isn't great, it would be nice if devuan took things other than sysvinit+initscripts more seriously. Maybe even just switch to OpenRC since, while it is still not great (please stop using pid files) it's a hell of a lot more sane than the mess of init scripts devuan ships with.

Re: Running systemd without systemd-journald

#30

Post by Arch-TK »

dark-star wrote: post #18
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 t…

The systemd man pages are a book. And, just for avoidance of doubt, that's not a good thing. I am never surprised when someone can't find out how to configure systemd to do what they want. It's just too enterprise grade.
Post reply on HN