Hacker News new | ask | show | jobs
by astrodust 3446 days ago
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"

3 comments

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.

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.

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

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.
That's nice, but adding it to the old log system is a one-liner, so it's hardly a reason to use Systemd.
> 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.

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

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.

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

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.
Got myself some "docker logs" and "heroku logs" also...
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.

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

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

Given that astrodust was mentioning "systemd init script" I'd think they are praising unit files and just got the terminology "wrong"...
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".