Earlier 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…
Running systemd without systemd-journald
51–60 of 79 posts
Re: Running systemd without systemd-journald
#52Would 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).
Re: Running systemd without systemd-journald
#53Earlier quoted context omitted.
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.
As someone pointed out elsewhere in the thread, so can systemd, your service did what it was configured to do. If you want the service to stay up when netdev goes down, then don't tell systemd that netdev is a hard requirement for your service.
Re: Running systemd without systemd-journald
#54Earlier 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'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.
Re: Running systemd without systemd-journald
#55systemd 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…
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.
Re: Running systemd without systemd-journald
#56systemd 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 was the first init/supervision system I used. I was able to understand how to use it pretty well. 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…
Re: Running systemd without systemd-journald
#57that 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)
Re: Running systemd without systemd-journald
#58Earlier quoted context omitted.
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…
> Windows 95 didn't have Swap it did have virtual Memory and swap
Re: Running systemd without systemd-journald
#59Quoted post unavailable.
What are you using instead?
Otherwise I’ve been using sinit with starlark based startup scripts. (Startup scripts can be any language in normal units, not just bash).
Re: Running systemd without systemd-journald
#60Earlier quoted context omitted.
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.