Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've never had data loss (assuming that's what "lossage" means), but here's an incomplete list of problems I've experienced on systems running systemd:

* System randomly taking 5+ minutes to boot

* Daemons sometimes not starting on boot

* Logging sometimes just stops (I confirmed this was caused by a systemd bug)

* Logging in over SSH starts taking 2 minutes and can only be fixed by reboot (I confirmed this was caused by a systemd bug)

It's not that sysvinit scripts are without bugs, especially race conditions and daemons inheriting environment when you invoke a restart script, but systemd appears to be distinct in that a seemingly-quiescent system can just suddenly stop working correctly. They had a low bar to clear to improve on the reliability of sysvinit systems, and yet they failed to clear it. That's not surprising given its excessively complex design.



Some random observations:

* System randomly taking 5+ minutes to boot

"systemd-analyze blame" can help identify issues relating to boot time

* Daemons sometimes not starting on boot

This most often occurs for me when services don't start quickly enough (too much contention on spinning rust and aggressive default timeout settings) so I have to adjust startup timeouts. "systemctl --state=failed" along with "systemctl status X" can usually help narrow down why your services failed to start.

* Logging sometimes just stops (I confirmed this was caused by a systemd bug)

I've found journald can get forcibly restarted if there is a lot of contention for disk iops and it can't checkpoint. I frequently run into this issue on a server that is used for backups for about a dozen or so clients that relies on filesystem snapshots.

* Logging in over SSH starts taking 2 minutes and can only be fixed by reboot (I confirmed this was caused by a systemd bug)

I've sometimes had this happen and for me it seems to be related to systemd-resolved deciding to stop responding to queries and the only solution I've found so far that actually works is to restart the system.

Despite the bugs I still prefer systemd over sysv-init - being able to run something like "systemctl status" and "systemctl --state=failed" to inspect the state of all services on a system has been invaluable to me.


> I've sometimes had this happen and for me it seems to be related to systemd-resolved deciding to stop responding to queries and the only solution I've found so far that actually works is to restart the system.

I hit this all the time on my Arch laptop and was a major impetus to switch to Void.


I really wish I could reproduce the thing on demand. I'd file a bug report but it has happened only a handful of times to me in the past 2 years and only on a single server. :-/


Void is like Arch before Arch started pissing me off.

I use Void, btw.


Heh I absolutely love Arch, and probably would never have made it to the point of being able to do Void or FreeBSD installs if it wasn't for Arch and its excellent docs. But yeah, some kinda annoying stuff with it lately.


Thanks for upvoting if you did, my karma is now 16,384!


Hackers used to say "win" to mean succeeding at some technical task, particularly if you gain some desired advantage, and "lose" to mean failure or being put at a disadvantage. Windows 11 is a losing operating system. Tree-sitter is a huge win for code editors. Etc.

"Lossage" means "the consequences of a lose" even if no data loss occurs. Some people consider systemd with its complexity and tightly coupled components to be a lose.


“Lossage” can also mean loss of service or other breakage. Any failure that wastes your time debugging and fixing the problem.


It has been ultra-reliable for me on 3 systems, over the course of a couple of years.

I can't say that about any of the other init systems you just mentioned.

> They had a low bar to clear to improve on the reliability of sysvinit systems, and yet they failed to clear it

systemd hasn't just cleared it, it has leapfrogged it.




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

Search: