7 ms·
At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it w
by alyandon 10y ago
At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me.
There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what the current state of services are on a system, being able to control the life cycle of a service including having systemd monitor and restart it, not having to deal with improperly written init scripts, etc.
Stockholm Syndrome perhaps?
- jcrites 10y agoRuss Allbery's investigation [1] into alternative init systems, in the Debian's project to select the best one, also viewed this systemd property in a similar way -- a surprising and unexpected benefit. Systemd's native understanding of cgroups, process hierarchy, and logging makes this view possible. [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989
- astrodust 10y agoThe idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) has a neat feature where you can watch logs easily, someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"
- nvarsj 10y agoI'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.
- dijit 10y agoWriting init scripts is as hard as you want it to be. and 99% of sysadmins are not writing their own, they're modifying the ones supplied by distro maintainers. If you're a distro maintainer then init scripts are something you write, something you understand because you're handling the state of your distribution from them. Of course you can just abstract away all the code to another bash script and have your init as 2 lines (which is what openBSD actually does).
- Xylakant 10y ago> and 99% of sysadmins are not writing their own, they're modifying the ones supplied by distro maintainers. and even here, systemd makes things easier, more straightforward and comprehensible by allowing to modify system-provided units via drop ins. No need to copy, I get updates to the original units as I'm supposed in a clean and well-defined fashion.
- yjftsjthsd-h 10y agoAd hominem aside... "journalctl -u sshd -f" is not straightforward because it's a _redundant_ new command when I already know grep and tail. Small tools handling text is a wonderful way to make a system easy to learn and powerful to use, and we're just throwing that out.
- detaro 10y agoGiven that astrodust was mentioning "systemd init script" I'd think they are praising unit files and just got the terminology "wrong"...
- rsync 10y agoI keep forgetting why I hate systemd (and as a FreeBSD user for all things, I have never used it) and then an article like this reminds me ... binary logs. Seriously - just reading it is painful. binary logs That's a lot of things, but it ain't unix.
- ajross 10y agoMeh. You get used to journalctl awfully quickly. For someone who never uses it, it's going to have some friction. You need to remember the command and how to spell it, which I'll admit isn't trivial compared to "just dig around in /var/log" style we're all used to. But you get over that hump in an hour. For the straightforward "?!$! something happened just grep for it in the log file" it's no harder or slower. And you start noticing things like -f and --since that have no good analogs in the text log world, and it seems like it has value. And every once in a while you need to pull magic like "show me EVERYTHING that was happening in the 3 seconds before this event, including kernel logs", and that's where it actually makes sense. I hated it too when I started using it. I don't mind so much now.
- XorNot 10y agojournalctl -u <service name> is an amazing improvement on dealing with logs. You get the immediate output of exactly what service you're interested in.
- yAnonymous 10y agoThat's nice, but adding it to the old log system is a one-liner, so it's hardly a reason to use Systemd.
- Fnoord 10y ago> For someone who never uses it, it's going to have some friction. Remember some people never used the previous init and logging systems. They're new to Linux or UNIX, they may be even young (and growing up with Systemd). Not just in this particular case but more broadly it is important to note there's going to be opponents who are used to X, Y, and Z and don't want to relearn or adapt. It is akin to the never ending progressive vs conservative argument. Just how large is the group though? Is there backwards compatibility? You see, I just use 3 Raspberry Pi's and I am apparently still able to use /var/log.
- majewsky 10y ago> someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f" $ cat >> ~/.bashrc alias logs="journalctl -f -u"
- takeda 10y agoNo it's nice, the biggest issues are IMO two: * it replaces significant part of the OS and creates a new APIs. It's not really problem of systemd itself, but once other applications start depend on the API you would need systemd to use it. This is especially bad for non-linux systems, like BSD for example, which need to write tools that will emulate such API. It doesn't help that Lennart openly is against any non-linux system so he won't make things easier * it's buggy, this kind of reminds me of Pulse Audio (also created by Lennart) although eventually things will improve, but it sucks on early versions of RedHat/CentOS 7.
- microcolonel 10y agoFor what it's worth, I don't think Lennart is against non-Linux systems; he just doesn't care. And as an avid OpenBSD user, as well as an avid Linux user, I can't blame him. Linux has great APIs like cgroups, inotify (in my opinion considerably more useful than the equivalent use of kqueue), and others. OpenBSD is the other unixy system which I think offers something valuable and unique, and it has its own APIs to offer that. I'm interested to hear how you got the impression that systemd is/was buggy. I have run systemd on a variety of systems, including pre-systemd-support Debian a few years ago; I was always shocked by how reliably it would bring up the system, consistently name the devices, and provide a convenient interface to the logs. I have been running systemd consistently on my workstations since Archlinux shipped it in 2012, and I have never run into a bug or poorly-documented feature as long as I have been using it.