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

61–70 of 79 posts

Re: Running systemd without systemd-journald

#61

Post by nybble41 »

mid-kid wrote: post #40
RedShift1 wrote: post #38

Earlier quoted context omitted.

Windows 95 ran an entire OS with decent UI in 8 MB of RAM. One really has to wonder, where is all the RAM going these days? I think the knowledge of doing anything with only 8 MB of RAM has gone away, we don't know how to do it anymore.

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…

Don't forget how much higher screen resolutions are these days. Color depth also. Those 8 MiB systems were driving single-buffered displays with perhaps 800x600 resolution at eight bits per pixel, with a color palette and dithering, which requires about 480 KB to hold the framebuffer image. Most applications would render directly into the framebuffer. A full HD (1080p) screen at 32 bits per pixel requires 8 MiB just to store the framebuffer (16 MiB with double-buffering), and that's not counting any of the input data or code needed for rendering. Figure on two or three times that to hold separate textures for each window (depending on the window sizes and how much they overlap) so that they can be composited live with desktop effects.

Re: Running systemd without systemd-journald

#62

Post by terrorOf »

ahartmetz wrote: post #56
gavinhoward wrote: post #55

Earlier quoted context omitted.

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.

No post body was provided.

Re: Running systemd without systemd-journald

#63

Post by heretogetout »

viraptor wrote: post #48
lokar wrote: post #47

Earlier quoted context omitted.

The fact that it can't seem to recover from a few bad records and gives up on the whole file demonstrates what terrible software it is.

Have you tried it? Journalctl does skip bad entries and prints out the rest automatically. If you've found a case where it doesn't, you should report that as a bug.

It may do that nowadays but it definitely didn't back when I experienced this issue. This matches my experience:

https://www.reddit.com/r/linux/comments/1y6q0l/systemds_bina...

Re: Running systemd without systemd-journald

#64

Post by viraptor »

heretogetout wrote: post #63
viraptor wrote: post #48

Earlier quoted context omitted.

Have you tried it? Journalctl does skip bad entries and prints out the rest automatically. If you've found a case where it doesn't, you should report that as a bug.

It may do that nowadays but it definitely didn't back when I experienced this issue. This matches my experience: https://www.reddit.com/r/linux/comments/1y6q0l/systemds_bina...

Yes, 8 years ago things had more bugs than today / were less mature. It's silly to call something terrible software today because of that. Everyone can find a pet bug they run into years ago. shrug

Re: Running systemd without systemd-journald

#65

Post by pengaru »

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

In a post-spectre/meltdown world syscalls are a bit more expensive, you'd be hard-pressed to compete with the journal's mmap windows especially for a warm page cache, using pread/pwrite. Especially if you just went naively about it and tried turning every little object access into its own little island of buffered IO. The objects in the journal are quite small, so you'd likely end up having to implement your own page cache/buffer manager in userspace to coalesce the syscalls.

It'd be far more interesting to explore an io_uring based implementation IMNSHO.

Re: Running systemd without systemd-journald

#66

Post by db48x »

heretogetout wrote: post #63
viraptor wrote: post #48

Earlier quoted context omitted.

Have you tried it? Journalctl does skip bad entries and prints out the rest automatically. If you've found a case where it doesn't, you should report that as a bug.

It may do that nowadays but it definitely didn't back when I experienced this issue. This matches my experience: https://www.reddit.com/r/linux/comments/1y6q0l/systemds_bina...

Lots of hardware problems on display, especially suspend and resume which is notoriously buggy (broken ACPI tables that happen to work in Windows so the hardware manufacture never noticed they were busted, etc). I recommend spending extra to get ECC ram, and running ZFS filesystems. Both can catch a number of types of errors before they corrupt your data. With those precautions I haven’t lost any data in many years.

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.

Re: Running systemd without systemd-journald

#67

Post by egberts1 »

viraptor wrote: post #41
egberts1 wrote: post #36

Earlier quoted context omitted.

it kills production daemons having long running stateful data whenever the netdev goes offline., systemd-networkd, that is.

Only if you configure it to do that. You can use Wants= and After= for your service to start it after the network, but not restart otherwise. 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.

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

Re: Running systemd without systemd-journald

#68

Post by lokar »

viraptor wrote: post #64
heretogetout wrote: post #63

Earlier quoted context omitted.

It may do that nowadays but it definitely didn't back when I experienced this issue. This matches my experience: https://www.reddit.com/r/linux/comments/1y6q0l/systemds_bina...

Yes, 8 years ago things had more bugs than today / were less mature. It's silly to call something terrible software today because of that. Everyone can find a pet bug they run into years ago. shrug

Not really a bug. A basic design flaw, since corrected it seems.

Re: Running systemd without systemd-journald

#69

Post by axy »

iforgotpassword wrote: post #21
axy wrote: 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.

Because systemctl status is called by monitoring tool. It's a habit, yes. If monitoring shows the service is down, no point to manually use systemctl, and syslog with ps become best friends. And sometimes date command as well. PIs don't have hardware clocks and wrong date may lead to errors that look mysterious.

Re: Running systemd without systemd-journald

#70

Post by viraptor »

egberts1 wrote: post #67
viraptor wrote: post #41

Earlier quoted context omitted.

Only if you configure it to do that. You can use Wants= and After= for your service to start it after the network, but not restart otherwise. 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.

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

It's not a networkd default. Networkd doesn't kill or even care about other services. The setting exists on the service's unit side. You have to explicitly specify how you want to depend on networking.
Post reply on HN