4 ms·
Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. They might not have been bet
by dagw 5y ago
Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts.
They might not have been better or more robust, but they where easier to understand and reason about. You could explain the entire thing to the most junior of sysadmins in a few minuets, tell them to read the boot scripts, and they would basically understand how everything worked.
- jbverschoor 5y agoReally? Have you ever written init scripts for a hand full of services for your typical saas application? It’s always been a mess, and I’m very happy systemd was copied from / inspired by Apple’s launchd.
- drran 5y agoThis mess is easy to solve with a library of functions to call, e.g. /etc/rc.d/init.d/functions, which can be imported and used. Unfortunately, there is no standard API for this.
- dagw 5y agoI'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.
- delusional 5y agoNaa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.
- spindle 5y agoThis. I can easily believe that systemd is an improvement in many ways for people who have time to understand it (especially in NixOS, as noted by another commenter). But I'm not happy that so many parts of Linux now have such a steep learning curve.
- kaba0 5y agoBut system init is a hard, complex problem. You can’t create a simple solution for that, since there is an inherent complexity. I prefer systemd over having a bunch of bash scripts trying to do service restart, logging, dependency management and failing at it. You would still get the same complexity but at a different (worse) level.
- cesarb 5y ago> But system init is a hard, complex problem. [...] a bunch of bash scripts trying to do service restart, logging, dependency management and failing at it. Playing devil's advocate: system init by itself is easy, just have a single script starting each daemon in sequence, like it was done in the distant past (IIRC, "init" started both the getty for each terminal, and ran a single startup script). It's the "service restart, logging, dependency management" part that's complicated. And unfortunately, since nowadays devices are often hot-pluggable, you can't really escape from the "dependency management" part.
- kaba0 5y agoDependency management is not only due to hot-pluggability, but inherent dependencies between different services. This is the same problem as with package managers and I would not necessarily say it is easy.
- generalizations 5y ago> But system init is a hard, complex problem. It's not. Read the shell scripts that openbsd uses to init. Simple, straightforward, easy to understand.
- mmis1000 5y agoUntil service restarts and error recover, log storage sneaks. In the past I just call pm2/forever(or something like that, I write nodejs most) to do the rest. Because roll those yourself... is really a pain. And a few months ago I retried that with systemd. It's really just about 10 line of configs. And you are done. Besides that, it also has a build-in scheduler with a command for you to tell when was the task runs, did it success? And what about the outputs. Although you could say it is just a cron replacement with better ui. But why no? I don't really care about the unix philosophy, I just care what do solve the problem for me.