Running systemd without systemd-journald(declassed.art) |
Running systemd without systemd-journald(declassed.art) |
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.
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.
Well the author seems to want text logs instead, which seems much much worse for this.
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.
It's almost the same result for the standard page cache when you're reading a file, isn't it?
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.
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.
It'd be far more interesting to explore an io_uring based implementation IMNSHO.
It's truly impressive how systemd turns out the be the right place to do absolutely anything and everything from bootloader to init to dhcp to ntp to network shares... except fix systemd bugs. systemd doesn't seem to be the right place to do that ever. Someone else needs to do it. For another example of this phenomenon, see the nohup bug.
Ever since then I switched to rsyslogd and the like. Rock solid.
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.
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.
Devuan
I see no reason not to consider it.
He is a Debian user who hates the way systemd works.
Devuan is for you.
that is my sentiment.
Linus was hesitant about binary logs.
I think they are just not unix. They are doing the wrong thing correctly (I would prefer doing the right thing poorly - or better yet doing it well)
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.
I still hate it.
Sorry, but understanding systemd does not preclude hating it.
In fact, it's because of the "haters" that I decided to dive deep into what init/supervision systems are and can be. Without that deep dive, I would have always thought that systemd was great. Afterward, however, I know just how wrong that is.
If a developer's only interaction with init systems was SysV init, yes, of course, systemd is the greatest thing since sliced bread.
But systemd could have been so much better...
Disclaimer: I'm writing an init/supervision system to be so much better. And simpler. Orders of magnitude simpler. Oh, and one that doesn't reach its fingers into every part of your OS.
tl;dr: systemd is better than SysV init, but it's not the end-all-be-all of init/supervision systems.
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
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.
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.
People complain about how bad or non-existing Linux's man-pages are compared to the BSDs, and then systemd comes along with a really extensive and well-written set of manpages and people complain that it's too much
Can't make everyone happy I guess...
There is no "system default" in the loop here at all. The service told systemd that it cannot operate without netdev, and systemd behaved accordingly. If the config was written more appropriately, it would have behaved accordingly. The "default" is what you had written in the unit file.
It's fine, I guess. But it did take a while to learn the new ways.
I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.
The behaviour you describe is not unreasonable to want: If your network device goes away, what exactly are you binding the socket to? How are you restoring the listening when it comes back up? But it's up to you to say which one you want.
“What did the Romans ever do for us?
… All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health”
Replace “Romans” with “Increased RAM usage”.
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.
it did have virtual Memory and swap
Windows 95 also didn't do things the modern way. It didn't keep an image of every application's windows in RAM. It kept track of what covered up what, and then asked applications to redraw themselves when needed.
Another huge amount is going to features like internationalization. Unicode is a beast that takes a good amount of code to implement, and Arial Unicode is a ~20 MB TTF file.
Modern luxuries like being able to tweet in Japanese are quite expensive.
https://www.reddit.com/r/linux/comments/1y6q0l/systemds_bina...
Though one time at work we had a few thousand hard drives from a particular vendor that had an interesting firmware bug. Very, very occasionally they would write a sector with incorrect data. No individual drive did it very often, but after a few thousand full drive writes we noticed it half a dozen times. We also discovered that the garbage data was always the same across all of the drives. Crazy. Sadly we weren’t running ZFS on those systems, which would have caught the problem and corrected it from redundancy. Thankfully we were able to get a refund. Never put your trust a hard drive.
To get back on topic, I’ve always assumed that journald was reasonably robust against minor corruption, but honestly I’ve never had a reason to test it. At the end of the day no one component of the system is solely responsible for data integrity; every level of the hardware and software must cooperate to prevent corruption else there will be cracks for the data to slip through.