Before if you knew the standard unix-ey tools you could get by. For example, want to list services? Just use `ls /etc/init.d/`. Want to monitor a log file? Use something like `tail -f /var/log/whatever`. Want to see what filesystems are supposed to be mounter? Just opne /etc/fstab with your favorite text editor. Sure, it wasn't super consistent but you used the same tools as you always used, whether you're editing source code or whatever. You had one very flexible toolbox that you had to remember the options on.
So as an example, how do I see what services are available under systemd? How can I reliable see what file systems are supposed to be mounted at boot? The answer to both of those tends to be "systemd spreads it's files and configuration all around the filesystem to you need to learn some bespoke systemd command that you'll only ever use for systemd".
And while those previous init systems were inconsistent projects like openrc demonstrate that it's possible to accomplish systemd's goals, greatly simplify that init system mess, without breaking principles like locality of behavior or "everything is a file", and to keep it compatible with things like grep and tail and all that.
>> How can I reliable see what file systems are supposed to be mounted at boot?
I still use fstab for this.
>> Sure, it wasn't super consistent but you used the same tools as you always used to.
You can still use most of the same tools. I use tail,grep,awk like I used to, but I like the fact that with systemd I get a system configuration layer (which includes the init system) rather than having different tools in each distro.
Do you prefer the old init system because it is something you are used to (and do not want to change) or do you have specific instances where systemd is broken for you ?
> With systemd, You can use journalctl to tail the log file by journalctl -u <unit> -f , so something like journalctl -u postfix -f
Last time I seriously used systemd I ran in to occasional log corruption. I've never not been able to just tail or cat log files even if they became corrupt (somehow?) but for whatever reason systemd can (or could?) get your logs in a state where they're unreadable with its purpose built journalctl tool. For example:
It was a long while back so I hope it's fixed by now, but I'm skeptical of the quality of the whole system given how much worse it was at reading files. (Compared to grep, which has never failed me.)
Sure, but how is that an improvement over locality-of-behavior and having unit files in easily known locations? Here's a rough list of places you can find unit files:
#Places you can find systemd unit files
/etc/systemd/system/*
/run/systemd/system/*
/lib/systemd/system/*
...
$XDG_CONFIG_HOME/systemd/user/*
$HOME/.config/systemd/user/*
/etc/systemd/user/*
$XDG_RUNTIME_DIR/systemd/user/*
/run/systemd/user/*
$XDG_DATA_HOME/systemd/user/*
$HOME/.local/share/systemd/user/*
/usr/lib/systemd/user/*
Now if you simplified that list you wouldn't need to learn a new tool and either memorize or look up a bunch of arguments. You could just have a sane directory structure and use some path globing.
With a bit more work (or possibly just a different balancing of priorities, with more care taken to locality of behavior) I think you wouldn't need some other tool.
I think you're really missing the point here, unix (the philosophy, not the implementation) is a programming environment. Yes, systemd has created tools to let you do most of the things you used to be able to do using standard tools, but there's a big difference between having a tool box and having a program feature.
A more complicated example, inotifyd is very useful, how could I go about triggering a script every time a log file is written to under systemd? When you start looking at these tools as part of a cohesive programming environment than you start to see systemd as full of edge-cases you have to account for. Lets say I want to count how many times a particular event appears in a log (quickly and easily, this isn't production) and send it to my cellphone. In unix-philosophy I can add something like this to my inotifyd-tab, `grep "some-event" | wc -l | pushbullet --push my stream`. How could I do something like that in systemd-land?
>Do you prefer the old init system because it is something you are used to (and do not want to change) or do you have specific instances where systemd is broken for you ?
I can see you're already dismissing the "unix philosophy" complaint, and really that is where I'd like to focus. Systemd will keep getting better in most cases, so that fact that I've had frustrations with it in the past isn't really a big deal. I'd be willing to deal with that if it was actually, you know, better than something like openrc.
But since you've asked, here's a non-exhaustive list of points that I've been frustrated enough to actually document them. I imagine a lot of them have been fixed by now.
Years ago I wanted to run debian on a kobo ereader. Unfortunately the built-in OS image was not running systemd, and the kernal was several revisions out of date. While I had no problem getting a debian chroot running, all of the services were designed to run under systemd, this made the whole project much more of a pain in the ass than it should have been.
By default systemd will kill long-running processes when I log out. Processes like screen or tmux. This has since been resolved, presumably by my distro somewhere, but took a solid while to figure out when that behavior suddenly changed.
When troubleshooting a raid array using a mipsel processor, I had persistent network issues. I took the boot media out for trouble shooting, but when I ~~chrooted~~ systemd-nspawned into the host to try to address the problem, I discovered that journalctl would segault. Thankfully /var/log still had all the entries I needed to fix the problem and binary logging wasn't enabled, or that would have been a much bigger problem. This appeared to be a general issue with running journalctl using qemu-static and binfmt.
For some reason my mother's computer can no longer resolve DNS. Ripping out systemd-resolved seemes to have fixed it, but not before I lost a few more hours.
I don't care where the files are. You're fixating on an implementation detail.
I want commands that achieve my goals. Where they get their info from I couldn't care less.
It seems you're more interested in reverse-engineering your system than actually doing something with it. Which is your right of course, but surely you can see how that can't be the priority of everyone.
It is true, across a bunch of different metrics I listed. Also an embarrassing amount of privilege escalation bugs.
I mean I don't know what you'd accept as evidence that it wasn't working well, but if you get an idea of what could actually change your mind on this let me know. I feel like I've more than documented the issues I've personally had with it.
I don't put your experience into question, I'm stating that I never replicated it.
I have 5 Linux machines and systemd made my life little better on all of them due to using the same commands and not having to pay attention to distro differences. I periodically backup logs and configs, I scan for errors and post them in private channels, I'm able to monitor if a service fell on its face, I have a small naive resource meter, and a few others.
I'm not an advanced sysadmin by any meaning of the word, but I know enough to make my life easier. Maybe you're using your machines in a very different manner that make systemd crap the bed? I'm merely saying that it doesn't do that for me.
> if you knew the standard unix-ey tools you could get by
And if you know the standard systemd tools, you can get by with systemd. It's far from enigmatic, the docs are freely available. Yes, systemd does things differently from what you might be used to, but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.
> how do I see what services are available under systemd?
systemctl list-units --type=service
> How can I reliable see what file systems are supposed to be mounted at boot?
You can still use /etc/fstab, systemd will parse it at boot time. For mount units, you can use:
systemctl list-unit-files --type=mount
> The answer to both of those tends to be "systemd spreads it's files and configuration all around the filesystem to you need to learn some bespoke systemd command that you'll only ever use for systemd"
/etc/systemd or /usr/lib/systemd for global stuff
$HOME/.config/systemd for per-user stuff
> but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.
I responded to that in another post, but basically unix is a programming environment and when you start composing tools together you get a powerful solution for quickly throwing things together.
That's kind of the point, it often prioritizes large enterprise needs over the convenience of lone sysadmins. Binary logs are great if you're a large enterprise who is paying to have those logs ingested into an elasticsearch cluster, but less useful if you're not at that scale, as one example. Systemd has great support for complicated log collection daemons, but makes it more difficult to just rsync your logs to some other server.
Systemd does not make people angry, they want to be angry by themselves for mostly religios and nostalgic reasons. Having a well integrated system is really valuable and saves you a ton of work and time. If you want to replace most of systemd features you need like 25 different softwares which all work differently, are configured different and are not that well integrated with each other which means you need to do more things and be way more careful that everything works together.
Devuan only has one and only one selling point: not systemd, which makes it for most people a unattractive choice.
[0] https://en.m.wikipedia.org/wiki/Systemd
[1] https://www.devuan.org/