Hacker News Reader

Comment by grifferz | Hacker News Reader

systemd has a number of features which are of interest to server operators, especially those who use containers, which may well be many of us before long.

Running systemd as pid 1 does not imply running a desktop environment.

I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM.

Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running.

I would encourage you to try it before deciding it's something you won't find useful.

Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.

View on HN

Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part of systemd that is the systemd-logind (that actually is a substitute of ConsoleKit that was deprecated god knows how many years ago). systemd has lots of features that makes sense on servers too. You may or may not need these features on your server, but systemd (as a init system) is still a better init system than sysvinit.

Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd.

  * it automatically cares about starting it
  * it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
  * it allows me to run the program as user with one line in the INI unit file
  * it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
  * it can create a private /tmp for my program

Actually, for desktops I don't care but for servers systemd is pretty awesome.

You hit on some of the points that won me over when I first started using systemd. Writing services is easy and logging their output is a breeze. Not having to fret with supervisor processes or daemonizing code shifts some of the complexity out of the application and into the init process[1] where I'd argue process management ought to live.

Given that targeting sysvinit for all the various sysvinit-compatible systems out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of whom have subtly different flavors for starting and stopping processes) better left to individual maintainers, it's nice that I can write a unit file and pretty much have it work on any system that's running systemd.

[1] I'm aware that some people might argue additional complexity doesn't belong in an init. That's fine. You're probably right.

And if there is a situation where your program is acting wonky, what non-systemd command can you use from the shell prompt to debug and reproduce exactly what systemd is doing?

> Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the nix ecosystem, I can't help but think that boat sailed long ago.

I was hugely resistant to systemd when Arch first switched, but I learned to appreciate it (the simplicity of unit files won me over). This came about a year and a half into my journey with Arch Linux when I was still learning that the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.

Though, journalctl still annoys me.

Sure, I can understand some of the hate directed to systemd simply on the merit that it does* do things differently--but it's hard to believe that the vitriol and insults from the anti-systemd camp are likely to help anyone's cause.

Personally, I like it, it works, I've not encountered the stability issues or other bits of weirdness some folks seem to insist regularly occurs (maybe it's distro-specific), but I'm also OK with being a statistical outlier. Or perhaps the anti-systemd crowd is disproportionately noisy.

> Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the \*nix ecosystem, I can't help but think that boat sailed long ago.

This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).

> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.

I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.

The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.

> "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Even if this claim were actually true -- what's wrong about that? Why should someone move to a new immature system if his current one works perfectly for him? If an Apache server works perfectly for me why should I invest time and effort to switch to nginx just to get the same thing?

I consider a fork a good idea because it would split Debian development into a safe area of old-fashioned reliable technology, and a testing area of new technologies like systemd. If those new technologies have proven their reliability _then_ the moment has come to think about exchanging old stuff. It is too risky to throw a reliable system overboard and to force all people into an immature new technology.

I wonder what's the problem with the systemd proponents. If other people prefer SystemV why don't they simply let them go?

> If other people prefer SystemV why don't they simply let them go?

You are free to fork Debian and modify it as you wish.

Compare that mentality to trying to get a big new subsystem into the kernel.

Torvalds is likely to require you to hammer out all the details and debugging in a separate tree. This even more so if it is replacing a tested, stable and maintained subsystem.

As such, it is the Systemd proponents that should be doing a fork. And run it alongside stable for a time to demonstrate that it works. Then people can move over at their own pace.

I'll look into that. Thanks!

Reply on news.ycombinator.com