[alyandon]

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?

[astrodust]

The 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) 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"

[rsync]

I 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]

Meh. 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.

[Fnoord]

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

[XorNot]

journalctl -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]

That's nice, but adding it to the old log system is a one-liner, so it's hardly a reason to use Systemd.

[regularfry]

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

-f is `less +F`, no?

--since is neat. You could hack it up with a sort and an awk, but it's nice having it built in.

[JimDabell]

> That's a lot of things, but it ain't unix.

UNIX has had binary logs since forever. utmp etc. are traditional UNIX and utmpx is standardised by POSIX.

[Frondo]

Eh, like the other commenter said, you get used to it.

Everything in life is a compromise in one way or another. Using journalctl instead of less? That took me about 5 minutes to commit to memory, and then...that's it.

I don't even think twice anymore about using one command or another to read the contents of the log.

[yjftsjthsd-h]

But you still need less, so now you've added one more command to remember for minimal benefit; less and grep are standard tools for working with everything, journalctl is a one-off.

[majewsky]

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

[nvarsj]

I'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.

[yjftsjthsd-h]

Ad 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.

[majewsky]

You still have it good. I'm already flipping forward and backward between tail/less on the legacy systems, journalctl on the current systems, and `kubectl logs` on the new systems.

[jononor]

Got myself some "docker logs" and "heroku logs" also...

[astrodust]

A) Yes I have had to write init scripts for production servers, and I've had to write whatever the hell they were before we had sysvinit. It wasn't always pleasant. There were times when you'd just edit things like /etc/rc.d/network and hack in some more commands.

B) I'm talking specifically about systemd init files, or whatever they're called. Given that they initialize things, that they replace conventional init files, the term applies.

[dijit]

Writing 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]

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

[detaro]

Given that astrodust was mentioning "systemd init script" I'd think they are praising unit files and just got the terminology "wrong"...

[astrodust]

What are they called, anyway? I know them as "that crap that lives in /etc/systemd where you can define services in easy to read INI-like files".

[detaro]

unit files: https://www.freedesktop.org/software/systemd/man/systemd.uni...

[jcrites]

Russ 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

[takeda]

No 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]

For 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.

[marios]

I think inotify is broken. If 'broken' is too strong a word, then it's at the very least misnamed.

It stands for inode notify, except there are edge cases where it doesn't actually report inode events. Consider this scenario:

  cd /tmp
  mkdir test
  touch test/somefile
  ln test/somefile linktothefile
  inotifywait -m test

Basically, you're monitoring a directory that contains a single file. There's also a hard link to the file, but it's outside of the watched directory. Since it's a hard link, they have the same inode number (you can verify this with ls -i).

If you append data to the file using the "test/somefile" reference, inotify reports the events as expected. If you do the same through the hard link, you get nothing. IMO this is wrong since you accessed the inode. inotify is more of a "report events on a file/directory" rather than a "report events on inode" mechanism.

[merb]

OT: well that problem is outlined in some articles about inotify. Probably most people don't care. Since they only want to watch a directory and their subdirectories and not edits from hard links.

[digi_owl]

He has in the past advocating ignoring everything unix about Linux when developing for it.

[MertsA]

No, he advocated for making design decisions based on what's best for Linux, not a compromise for other operating systems.

[grandinj]

that's not a very charitable view. He simply does not get bogged down in debates about what constitutes the true "unix approach", and prefers to focus on building the best system that can be built using the facilities Linux has to offer.

[rektide]

This (creates a new APIs) I feel is very much at the root of many people's dislike. But it's also exactly what was most important for advancing star-nix.

Historically we've had very little for managing processes. Start stop restart is about all we get for public interfaces, and they all involve shelling out via system().

The entire rest of the computing world has gotten immensely rich and powerful and grown. It's grown because there have been APIs. OpenStack, AWS, Kubernetes- once other applications start depend on the API (as you say) things start getting really good and powerful. The API makes it usable, gives the thing having an API programmability.

Process management has not had a decent API until systemd. Now we can write programs that watch for units being started, watch for them failing. Everything, the whole world, suddenly has a consistent well integrated API. It's appalling to me that people would disfavor this, when the past has been a bunch of hand jammed /etc/init.d/ scripts with varying capabilities and little introspectability.

I agree that being non-Linux is absurd and unfortunate. There really can't be that much special sauce that was relied on. Umass-PLASMA group has systemgo which is an interesting alternative, imo. https://github.com/plasma-umass/systemgo