>> 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.
>> it was great having a perfect call connection anywhere there is decent internet.
Thats the catch. The internet service has to be good enough for VoIP. Many times, having the right router is key.
>> I'd pick up the handset and the dial-tone was immediately there;
As long as the handset thinks its registered, dial tone will be immediate.
As far as the Ooma experience goes, if you can change the codecs for your device to use something like G722 rather than the normal PCMU/PCMA or GSM, call quality should be good. What handset did you get for your Ooma service ?
Thanks for replying! When I had the Avaya phone, in most all locations & conditions, if there was decent (e.g. a non-tech person's home in latin america, an apartment in London, a residential cable modem in turkey) - the call was crystal clear. Meanwhile, Skype, Google Voice, Viber, and even WebEx sounded cloudy. I always wanted to know what the "secret sauce" was that allowed this device (or the company-hosted server behind it) to have this quality.
And I bought the headset (which connects to the base station as another phone, rather TO the phone. The process to simply dial a number and use the headset is comically complicated to "join" the calls...)
If you have any specific advice for this setup, I'd be appreciative. Likewise, if you have other recommendations for solutions, I'm all ears. Thanks again!
https://news.ycombinator.com/item?id=36799776 https://github.com/bartobri/no-more-secrets