Live data from Hacker News

Running systemd without systemd-journald

declassed.art

51–60 of 79 posts

Re: Running systemd without systemd-journald

#51
post #5

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…

512MB is absolute overkill for the application that you built, it is the choice of OS + the tooling used that resulted in that requirement. Not all that long ago 32 MB served a whole bank, and embedded systems used kilobytes of RAM, not megabytes. We've gotten so used to slapping a full unix server into stuff that we hardly even think about it any more and just take that kind of power completely for granted. I'm not saying you made any wrong choices, it's just that most of the embedded stuff that I come across would be just as feasible on a fraction of the CPU (and power) budget than what we typically choose because for instance Lua is such a convenient choice for a platform like that.

Re: Running systemd without systemd-journald

#52
post #19
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).

This is actually extremely useful for me to know, so thank you so much for pointing this out!

Re: Running systemd without systemd-journald

#53
post #42

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

Its never a good systemd-networkd default to be killing daemon whenever a netdev goes “cricket”.

Re: Running systemd without systemd-journald

#54

Earlier 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 quite annoying to not be able to use common tools for DNS queries like `dig`, when using `systemd-resolved` for DNS. I think you might have to sometimes flush the caching feature of `systemd-resolved` as well.

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

#55

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

#56

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

I have similar experience with PulseAudio. First look: it's unstable: Second look: it's fairly well thought out. Third look (using it as a programmer to implement some audio routing thing): it's kind of garbage. I am now using Pipewire, and Pipewire is pretty great and very flexible because it has the right foundations, so it can do anything.

Re: Running systemd without systemd-journald

#57
"when I needed systemd binary logs? - and I realized I never needed them."

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)

Re: Running systemd without systemd-journald

#58
post #49
post #40

Earlier 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

Can confirm. I remember it swapping heaps on my 32MB machine.

Re: Running systemd without systemd-journald

#59

Quoted post unavailable.

What are you using instead?

I use runit when I need process supervision from my init: https://wiki.archlinux.org/title/runit

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

#60
post #3

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

That (syslog,ps) method was likely formed by habit during the many years before systemctl existed.
Post reply on HN