Hacker News new | past | comments | ask | show | jobs | submit login

systemd is not perfect. Debugging systemd is still very hard. There is no way to simulate what actions would be performed to reach a target without actually executing them. There are plenty of issues related to boot and shutdown which are _hard_ to track down because of this.

The journal is nice, especially on desktop systems, but it's way too slow to be used in any moderately busy system. The disk space utilization is also _prohibitive_ for archival.

We still rely on remote syslog because of this, but it's not without issues: the journal->syslog translation is lossy, and it's compounded with some "quirky" upstream decisions (purely cosmetic) to write unit descriptions in the log as opposed to the real unit name which make tracking down units harder if you don't have the actual journal file.

Journal files also get corrupted easily with unclean shutdown. In case of issues (from software to hardware), the local journal quickly becomes completely useless.

All in all, systemd is an improvement, but it lacks the debugging tools, performance and overall polish you would expect from a central piece of software such as init.

The internal APIs are mostly undocumented or self-referential. The DBus interface is opaque. Things gets muddy very fast as soon as you touch non-central components such as systemd-resolved or networkd.

I'm not a detractor, but there are many things systemd can still improve, but it feels we're kind of stuck. I'm quite happy if we have some competition here.




The journal files can get corrupted, but it's a localized corruption that journalctl skips over and continues on without additional data loss. Obviously anything that didn't completely commit is gone, which would be gone anyway with some other format. The main difference is that systemd-journald can a.) become aware of the corruption, b.) warn of it rather than display corrupt info, and c.) recover and continue on.

There have been a pile of bugs I've run into and reported where journald gets really confused; e.g. 'journalctl -b-5' won't actually go back five boots, it'll show some other content, or it'll give an error, but using --since will work fine. I haven't seen this problem recently, so the fix may be trickling out.


That's not my experience -- once corrupted it stays corrupted. Is this something that's been fixed since Ubuntu 16.04?


I don't know what you're contradicting because I never said the corruption gets fixed. I said it's skipped over. Specifically what happens is upon detection of corruption, journald stops writing to the corrupt journal file, creates a new journal file, and new entries go there. The utility for reading the journal files, journalctl, can also detect this corruption and will skip over detected corruption and continue on.

I have no idea what version of systemd Ubuntu 16.04 has, but in systemd-233 I'm not seeing aforementioned problems with -b switch and corrupt journal files.


> Journal files also get corrupted easily with unclean shutdown.

Huh? I thought that they introduced this weird binary log format precisely to avoid this kind of error. (I don't remember the exact reasoning, though.)


You're confusing the binary format with the tamper protection, or file "sealing". The two features are really independent.


"They" were not very successful in this, like they weren't in any other stability related feature.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: