Hacker News Reader

Comment by Nextgrid | Hacker News Reader

The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?

View on HN

For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors.

When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing.

With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem.

I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.

Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?

I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.)

I'm talking about being able to rule out causes because the primary components of the system are independent of each other.

> is a lot easier to do in a dead system when they're text and not binary

The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything)

I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.

For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy?

I've never tried.

I like service files, but the rest not so much.

journalctl -D /mnt/othersystemroot/var/log/journal <...>

I tinker on my gentoo box and OpenRC is more than capable of everything it needs to do. I don't understand why people's linux fill up with "trial and error custom shell scripts".

Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.

It is a straw man that people use to try to try to make systemd seem like a solution, the only issue is that the problem never actually existed, just like people who try to argue that "x is dying or not attracting enough new users" in order to try to present a change they want to make as some how "solving" the problem of users leaving (e.g. "we should switch development to github"). When you look at the numbers and look at the existing systems, the stories are a complete fabrication to try to prop up a fallacious argument or process, tool, or project that is usually worse than what is really out there, not what its proponents claim is out there.

It's not that your system fills up with them from your side. It's that the old approach of not-very-synchronised shell scripts is very fragile and sometimes arrived to via trial and error. And many services carry their own custom implementation of those.

For example mysqld_safe is there pretty much to handle things that systemd can do, but initd can't. Some other services have custom wait-logic to make sure dependencies are ready, which is covered by service readiness notification in systemd (see just yesterday https://news.ycombinator.com/item?id=25845143). Many services do custom pidfile handling (see the fun implementation in openssh init file - your pidfile path better not have `=` in it) just because initd has no idea of services.

Basically every service I've seen which has more than a single line in start and stop functions in broken is at least one subtle way. (and close to every single status function - no, existence of the pidfile and that pid running an undefined process is not the same as service functioning) Systemd provides 99% of what those init scripts try to achieve as simple configuration and if something's missing you can still fall back to executing a script instead.

for me the downside is mostly when I am forced as user to everything the 'systemd --user' way. All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config (the script that starts sway or xinitrc whatever) and I do not need systemd and journalctl and all the tooling that I'm then also buying into. This is IMO an annoyance where I think systemd is creeping in too much.

From a developer pov I'm optimistic. systemd seems to be positioning itself as a isolation technology. It gives me a simple and effective way to ship security controls that the user themselves would not be able to do with this granularity (well normally) and it's part of the package / installer (e.g. by default hardened because why bother the user?). And the process for me as dev is really simple too (see below).

It gives me additional options rather than just hope everyone will use firejail and apparmor (even on a debian sid apparmor userspace is too permissive or not properly maintained - firejail is better but rare).

some simple things that can be dumped into a systemd.service file (source https://www.redhat.com/sysadmin/mastering-systemd) to ensure hardening isolation/hardening is always shipped with the package.

  RestrictNamespaces=true
  RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
  ProtectClock=true
  NoNewPrivileges=true
  DevicePolicy=closed
  PrivateTmp=true
  ProtectControlGroups=true
  ProtectHome=true
  ProtectKernelLogs=true
  ProtectKernelModules=true
  ProtectSystem=strict
  RestrictSUIDSGID=true
  SystemCallArchitectures=native
  SystemCallFilter=sendmsg recvfrom sendto getpid prctl brk socket read stat openat rt_sigaction fstat bind close connect getsockname setpriority capset getpriority lseek mmap mprotect munmap access execve getuid capget arch_prctl gettid
  RestrictRealtime=true
  LockPersonality=true
  MemoryDenyWriteExecute=true

As an elitist user, sure firejail is great - but I would not install firejail on my 72 yro aunt Debian laptop (because many reasons :))

>All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config

The thing is, you want service management here. Sway is not a service manager and won't handle monitoring of the processes, socket activation, logging, etc.

> platform-specific commands into a single, consistent interface

Consistent interface that only works on one platform and uses all the platform specific commands imaginable to do things that have no reason to be platform specific. And it doesn't even play well with other parts of that same platform.

>to do things that have no reason to be platform specific.

If you ever try to port systemd code to non-Linux platforms you will see that this is not true. There are lots of things in Linux that have no real analog on other platforms, and it seems strange to fault a project for taking advantage of those. (BSD is the same way when you get into that too)

Reply on news.ycombinator.com