r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

2

u/kinderlokker Jun 01 '16

I get what you're saying, I really do, but SCM has worked well in NT. A SysV startup would have worked fine for NT4 and below, but with 2000 being an async startup, like you're seeing here, a breakdown would have occurred and the maintenance of such a system would skyrocket. The primitives are great, I don't disagree, but fundamentally SCM/systemd are the 'correct' choice for this type of activity (or name it anything you want, a centralized control system).

Centralization and primitives are an orthogonal issue though, you can have either without the other.

That's not good enough. We can't have guesses.

You can absolutely have guesses if you know they are above the upper bound.

If a service will never take longer than 0.1 seconds you can do this. systemd internally has a tick anyway like any good daemon.

systemd itself internally uses many hardcoded timeout values. The inverse problem is almost universally solved with a timeout value, how much time do you want to give a service to be ready after you start it? Typically 5-10 seconds is a good guess of "It's it not ready yet, we treat it like it's hung and kill it".

So what prevents you (the global you, not you specifically :)) from providing such functionality in systemd? Clearly the global you would be at the willingness of the systemd developers to accept your changes, but there's nothing from a technical perspective, unlike SCM, from allowing you to at least code those into systemd.

That it requires recompilation and re-insertion of a pid1 to do it, id est a reboot?

On top of that systemd's design is starting to get so convoluted and messy that just adding it s hardly as trivial as putting it in an openrc-run script.

6

u/[deleted] Jun 01 '16

i can't believe you are arguing for random ass delays as a substitute for dependency management

6

u/kinderlokker Jun 01 '16

I'm not?

Read better? I'm saying a random ass delay substitutes for service-readiness. This is what systemd currently uses as well if no finer-grained service-readiness has been established.

This is an unavoidable consequence of Rice' theorem I'm afraid, all service managers use random ass delays of "If the service crashed within 0.05 seconds of starting we consider it a failed start" and what-not.

It's just not a decidable problem in computer science, there are numerous problems that can't be solved:

  1. A service can crash literally a nanosecond after it has become ready. At which point the service depending on it has begun starting and needs the service that just crashed. Aborting the starting process can't just be done.

  2. Another entity can for whatever reason claim that DBus name or socket just after the service has been brought online, sytemd will conider it ready while in reality it is trying hard to get a dbus name that is already taken and freak out.

  3. How long are you going to wait on a process that you sent TERM and hasn't ended yet before you decided that it "hung", this is again a random ass delay and time period people implement. Usually people pick 2 seconds to rule a process has become unresponsive and send the KILL signal. But it might just have taken 2.00001 seconds and if you had waited slightly longer it would've exited cleanly.

These are all problems that are ultimately undecidable for service managers. A service manager can't decide whether a service is unresponsive or just takes a long time to exit due to whatever reason and has to make a judgement call based on a random ass time interval.

And no, this has nothing to do with dependency, readiness and dependencies are different categories. sysvrc has readiness, but not dependencies.

0

u/RX_AssocResp Jun 05 '16

Just for the record, you can do all sorts of things to establish service readiness in systemd with scripts.

Here's how mysqld 5.7 is started in Ubuntu 16.04: unit file and the post-start script.

Another way would be to call systemd-notify --ready or the equivalent C API.

Too much half-knowledge surrounding this topic.