Hacker News Reader

> systemd supporters are mainly desktop users

> is important to listen to server admins that know what they are talking about

Huh?

I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed.

Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management.

Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script.

Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!)

I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.

I am not saying that all/most sysadmins hate systemd , I am just annoyed but the random Joe Desktop Linux users throwing his opinion. I like reading sysadmin experience and what issues they have like you but also ones that had issues with systemd bugs and behavior and a random Fedora user will show up and repeat something he has no clue about.

I personally had no issue with systemd or upstart or any other I used so I would wish desktop user like me would read more and comment less about what is better.

Are the uninformed opinions of joe user really influencing decision makers? The internet is mostly filled with people spouting uninformed opinions, it does not seem worth it to spend any energy caring about it.

I don't think the decisions made in Debian were influenced a lot by the average joe user, my complaint is about the discussions, my complaint is that say if I find a thread that compares all the init systems I would prefer to read expert opinions on it, people that had success with systemd but also people that had trouble with systemd , but you get average joe pasting same shit all the time on both sides.

But yeah you are right(this always happens on the internet), I was also guilty of this, I remember back when C# appeared and I was sure is the best thing ever and it will soon replace all the other languages. I think at my past enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and in 3 years it will dominate.

My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use systemd functionality as developer, but then you are no longer portable to bsd, darwin or other systems. I think systemd is bad because it will break links between the various unixes. That being said, as system administrator, I found systemd mostly to be ok, but sometimes you run in non reproducable problems. I have sometimes that servers don't come up, because the network unit didn't get started. Restarting fixes it. I haven't been able to reproduce it and the logs are also not very helpful.

I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology.

I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.

If I understand correctly, GP is saying that systemd also provides non-init-related functionality.

If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.

> If your package relies on other systemd capabilities

Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.

Logging, login, network configuration, and more. https://en.wikipedia.org/wiki/Systemd#Ancillary_components

These are not APIs, they are UIs. They will not cause vendor lock-in for general user-space applications.

For Init, desktop use-cases can be challenging. They can cover hot-swap networking, hot-swap hardware, sleep/restart.

Scenario: a user is playing an audio stream that comes over the network. They put their computer to sleep. They restore it later, at another site.

Consider the dependency calculation to restore that mixing pipeline, without sending clicking noises to the user.

> depends on a systemd component

It depends on a systemd API and there is an independent implementation, elogind. GNOME runs just fine in the BSDs, so its dependency on systemd is a strawman.

I only use linux on servers, and have been doing that since I used redhat and slack in the '90s. After that I moved to FreeBSD and since about 15 years, I'm on Debian.

sysvinit scripts are horrible to create and operate. It's easy to set tup dependencies for network or other services. I haven't used it to run cron-like tasks, or inetd-type servers, but I don't have a need for that.

I dislike it for the fact if a process hangs or if your network isn’t ready you get “Starting process - 2/5minutes”

If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes”

Sure, you can alter the timer but that’s then just another task I shouldn’t need to do.

Dependencies within unit files

It’s own log formatting in a binary format

It’s icky, it feels clunky and while it works it doesn’t feel smooth.

This isn't actually an issue with systemd, it's just how the distro has configured it.

systemd is really good at doing what it's told, if it's told something bad it will do something bad.