Systemd is a horrific abomination at this point it just never ends...
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.
I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
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.
I've never tried.
I like service files, but the rest not so much.
Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.
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.
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
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.
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.
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)
What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gave out and switched to systemd, I saw the writing on the wall and drank the kool-aid. I haven't had any regrets.
I feel like it was mostly a missed opportunity to do things better; the declarative unit stuff is both over and underspecified, and for anything nontrivial, I always end up with sidecar scripts, anyway, which makes the whole thing just a game of useless boilerplate.
And then it started attempting to assimilate other daemons...
Like I said, it is what it is. But what it is is a barely competent make-work replacement for something that wasn't the worst problem in early-startup, anyway.
And screw unit files. Is there a helper utility to write and place the unit files for me? That would make me actually shutup about systemd.
I am honestly surprised we haven't seen a good GUI pop up around systemd yet that allows for simple service creation and configuration like that.
If others were similarly curious, the "/index.html" isn't pedantry, just navigating to "/" is a separate welcome page that shortly thereafter redirects to the freedesktop.org site
Just turn on reader-mode in your browser. Or prefix the url with `about:reader?url=`.
> that shortly thereafter redirects to the freedesktop.org site
Specifically, it redirects to the systemd documentation part of the freedesktop.org site. There's also a bunch of other documentation redirects for the stuff I use. That's what index.html describes.
Try finding the documentation online to write a systemd service. Google finds tons of useless results and good luck remembering the freedesktop.org URL for systemd documentation (or even knowing that it's the _freedesktop.org_ link that is authoritive), or try navigating their landing page. It's a f#$%ing nightmare!
Just go here instead. https://systemd.software/service. Super short and easier to remember and easier to discover than `man service` oh wait I mean `man systemd` wait no I actually mean `man systemd.service` because `man systemctl`. Wait where do I even put the .service file???
The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*`
This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.
If you search for `man service` you get linked to SysV init scripts [0] and are led astray if you don't know that sysv init scripts aren't systemd.
If you search for `man systemd` you get linked to a huge man page [1] which isn't approachable to a novice. There isn't an `EXAMPLE` section like there are on other man pages and searching for `example` doesn't reveal any commands to run. It doesn't describe where you can find an example service (unless you magically know that a "system unit" is a service and there's even a gotcha to that: it doesn't have a `files` section to describe where files are at (contrast with `man ssh_config` or `man nginx`) and it is absolutely not clear that the directory is hidden behind an obscure `pkg-config` invokation. Good luck discovering other services you can learn from by reading their service files!
If you managed to do `man systemctl` [2] you reach equally poor documentation. Again, no `files` section and this time not even a mention of `pkg-config`. There's a ton of mentions of environment variables (why does the _system_ need environment variables???). It describes how to "list" units but doesn't describe that it _won't_ list your user units (or, won't list the system units if you do --user). It doesn't describe how to _create_ a unit. It doesn't clearly walk you through the steps (again, there are no examples) so it's up to you to figure it out and hope you don't fuck up your system.
If you search for "just" `systemd`, you arrive at systemd.io [3]. Again, this site is not approachable to a novice! There's just lots and lots of reading. A _lot_ of reading. There's a few "examples" scattered everywhere in the form of an example command to run and a description of what it does. But _nowhere_ is there a single example with everything tied together into a single Hello World style solution.
[0] https://linux.die.net/man/8/service
[1] https://man7.org/linux/man-pages/man1/systemd.1.html
Yeah, because that's the thing you want help with.
No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.
Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query, but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.
No it isn't. I, as a power user and only as a novice system administrator, want to "run a program at startup".
It's not clear to me that it's `systemd` that manages that. It's not clear to me that it's specifically `systemd.service` that I need to find help with.
> No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.
But... why???
> Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query
Yes, I do assume that because it describes me. I'm sorry you think I'm stupid though. Get off your high horse and start thinking of people with different experiences than yours.
> but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.
Searching Google for `systemd service` puts a link to freedesktop.org with a very un-memorable URL. I didn't even understand that "freedesktop.org" is the authoritive site until a few weeks into learning systemd. I definitely won't remember to type in "freedesktop.org/software/" before trying to find systemd documentation. And I don't want to have to use Google as a relay every time I want to read the documentation for systemd.
So I made a site that does it for me.