[traverseda]

>>You can do systemctl list-unit-files

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.

[mischief6]

> 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?

https://www.freedesktop.org/software/systemd/man/systemd.pat...

[pdimitar]

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.

[traverseda]

I think you're missing the point that you can have both, a system that works well and adheres to basic unix philosophy.

[pdimitar]

And you claim systemd is not working well, which is factually not true.

[traverseda]

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.

[pdimitar]

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.