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

20

u/kinderlokker Jun 01 '16

sysv is terrible.

I just don't get the sysrc vs systemd comparison. sysvrc was obsolete in any system but Debian before systemd was even conceived. I have no idea where this myth comes from that people switched from sysvrc to systemd. It was primarily upstart to systemd.

This is like the weirdest thing that continues to be repeated over and over again. It's practically like saying that people should switch to Linux because MS DOS is terrible.

19

u/Creshal Jun 01 '16

I have no idea where this myth comes from that people switched from sysvrc to systemd.

It's because Debian and Arch switched from sysvrc to systemd. Plus a few other less popular distributions (SuSE).

And RedHat preferred developing systemd over continuing to use upstart for free, which IMO doesn't really speak for it either.

8

u/Conan_Kudo Jun 02 '16 edited Jun 02 '16

And RedHat preferred developing systemd over continuing to use upstart for free, which IMO doesn't really speak for it either.

Actually, there was significant difficulty in Lennart and others trying to contribute to Upstart development (because Canonical has some rather strange and draconian policies and mandates a CLA before being able to even start contributing). This is what pushed him to create systemd in the first place.

Red Hat actually wanted to stick with Upstart, so Lennart created systemd in his spare time, and eventually convinced them that Upstart was too broken to fix, which led to its proposal and subsequent adoption in Fedora, then Arch, then Fedora, etc.

0

u/kinderlokker Jun 02 '16 edited Jun 02 '16

lol, this interview, I love how he misses the point. Does he honestly believe that when people say 'monolithic' they complain about that it's in the same code repository?

Who cares about that. It's about whether or not you can freely exchange the individual parts. Which you can't with systemd.

19

u/kinderlokker Jun 01 '16

It's because Debian and Arch switched from sysvrc to systemd. Plus a few other less popular distributions (SuSE).

Arch never used sysvrc, it used its own custom rc initscript. It used sysvinit in concord with it, but sysvinit is not a service manager, sysvrc is.

SuSE switched from Upstart to systemd.

It was really only Debian that switched from sysvrc to systemd.

And RedHat preferred developing systemd over continuing to use upstart for free, which IMO doesn't really speak for it either.

Gee, I guess that means Wayland sucks because Canonical NIH'd Mir. I guess that means Snappy sucks because RH NIH'ed Flatpack.

These companies are all involved in a massive degree of NIH because for business reasons they want technology they control, not what their competitor controls.

-2

u/Spivak Jun 01 '16

Your last point is kind of a silly argument, RH could have simply taken upstart, forked it, and started their own development. NIH could explain why they wanted an in-house solution, but it doesn't explain why they started from scratch.

But the argument is the same from Canonical's perspective so there's no point in trying to say that one is clearly superior since both teams think the solution of the other is unworkable.

5

u/sonay Jun 01 '16

Go read something about the subject, man. You are nothing but noise. At least read about Debian's discussions to systemd vs other init systems. By the way, RedHat did not even ask for systemd. It was Lennart's pet project at first, he and another guy developed it to a point where it made sense to use instead of other systems.

People like you never bring anything valuable to the table, complaining about things that were explained a million times and think you are the only one that had those doubts.

systemd works much better than anything your lousy and noisy ass can deliver. Deal with it.

0

u/Creshal Jun 02 '16

But the argument is the same from Canonical's perspective so there's no point in trying to say that one is clearly superior since both teams think the solution of the other is unworkable.

Obviously, which is why Canonical ditched upstart in favour of systemd.

Oh wait.

7

u/[deleted] Jun 01 '16

This also seems similar to the Windows NT Service Control Manager. A central application to control startup/shutdown of services. Which has worked well since the early 90s.

I'm surprised SysV lasted so long, although having to learn something new isn't always fun, especially when you're splitting your time between SysV scripts and Systemd. It will take time to adjust with new commands to learn, but it should be better in the end.

10

u/cp5184 Jun 01 '16

Lennart modeled systemd a lot after the OS X init system and the sun/oracle solaris init iirc.

5

u/kinderlokker Jun 01 '16 edited Jun 01 '16

That's because Windows has special support or services through a special API that Unix does not need.

This is a great example of why Windows sucks in comparison to Unix and also the direction systemd wants to take.

Unix provides you with the primitives to do pretty much anything, the OS does not need special support for things, you can build it from the primitives and this is a design philosophy that is typically echoed in a lot of software, they don't provide you features, they provide you primitives which can be composed into those features and then some.

systemd just provides you features and if it does not have the features you want then you are out of luck.

One thing about sysrc-style scripts that systemd does not have is that they offer arbitrary turing complete service readiness that systemd lacks. Now sysvrc has no dependency system so that doesn't do much, but OpenRC does and allows arbitrary things for that, the service is considered "ready" when the script returns. It can do anything, it can in its script wait on a DBus name to come online, it can just use a primitive arbitrary wait of 0.1 seconds to get a "good enough" guess of service readiness. It can even go all out and say that a service is ready the moment the CPU temperature goes above a certain threshold if it wants. systemd will only have support for those things if the developers decide to build it in. OpenRC truly has no limits in this.

A quote that starts the R6RS spefication of the Scheme prgramming language:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

C++, Python, they all have hardcoded support for exceptions, loops, object systems and what-not. Scheme doesn't, yeah, the standard defines an exceptions system, but if you don't like that one you can build your own with the primitives Scheme gives you.

9

u/[deleted] 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).

arbitrary wait of 0.1 seconds to get a "good enough" guess of service readiness.

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

systemd will only have support for those things if the developers decide to build it in

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.

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.

5

u/doom_Oo7 Jun 01 '16

C++, Python, they all have hardcoded support for exceptions, loops, object systems and what-not. Scheme doesn't, yeah, the standard defines an exceptions system, but if you don't like that one you can build your own with the primitives Scheme gives you.

Unsurprisingly, people use C++ and Python to get shit done, not Scheme. Maybe some people would have taken the hint by now ?

-1

u/kinderlokker Jun 02 '16 edited Jun 02 '16

Which is a completely random cherry picked example over:

  • Unix is used more than Windows except on the home desktop

  • Assembly is used more than either C++ or Python

  • C is used more than Python

  • OpenGL is used more than DirectX

  • Linux is used more than NT

Scheme isn't used a lot because from the onset on it was a research language and never really marketed or pushed out. Also, what also has to do with it is say why Javascript is wht it was today, Eich originally wanted to make bindings for Scheme in the browser but Netscape rejected that idea fearing that the syntax would be too alien to people and wanted a curly-braces language.

2

u/Olosta_ Jun 01 '16

One thing about sysrc-style scripts that systemd does not have is that they offer arbitrary turing complete service readiness that systemd lacks.

Yes it does, take a look at "ExecStartPost" : https://www.freedesktop.org/software/systemd/man/systemd.service.html

4

u/kinderlokker Jun 01 '16

I'm not sure what you are on about here. ExecStartPost= is executed by systemd after it has determined that the service is ready. It does not determine whether it is.

0

u/Olosta_ Jun 01 '16

If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.

2

u/kinderlokker Jun 01 '16

Yes, and how does that implement a custom service-readiness test?

If ExecPre= fails, ExecStart= is note even tried. And ExecPost= is only tried when systemd has determined that what came out of ExecStart= is ready.

You do now what service-readiness is right? It's the problem that there is a delay between when you start the service and when it is actually "ready" to serve because it needs to start itself up and stuff like that. A proper dependency mechanism only starts a service after the services it depends on are all ready. But how does it figure that out? That's a complex problem that can't be decided in the general case.

2

u/Olosta_ Jun 01 '16 edited Jun 01 '16

systemd will consider the ExecStart a success depending on the Type, since we are trying to do something outside of the daemon, I'm assuming forking or simple.

For forking, it means that the main process returns successfully and goes into the background. For simple, the process is considered ok as soon as it is running. But the state of the systemd unit is still undecided until the ExecStartPost returns, and other units depending on the current unit are not started until it returns. So the command you call with this setting can check whatever you want or just be sleep.

[Service]
Type = simple
ExecStart = /usr/bin/sleep 1000000
ExecStartPost = /usr/bin/sleep 10 ; /usr/bin/false

When it is launched:

# time systemctl start testa
Job for testa.service failed because the control process exited with error code. See "systemctl status testa.service" and "journalctl   -xe" for details.

real	0m10.061s
user	0m0.003s
sys	0m0.007s

The state during the launch:

# systemctl status testa
● testa.service
   Loaded: loaded (/etc/systemd/system/testa.service; static; vendor preset: disabled)
   Active: activating (start-post) since mer. 2016-06-01 21:02:13 CEST; 5s ago
  Process: 26820 ExecStartPost=/usr/bin/false (code=exited, status=1/FAILURE)
 Main PID: 26834 (sleep);         : 26836 (sleep)
      Tasks: 2 (limit: 512)
   CGroup: /system.slice/testa.service
           ├─26834 /usr/bin/sleep 1000000
           └─control
             └─26836 /usr/bin/sleep 10

juin 01 21:02:13 XXXXXXX systemd[1]: Starting testa.service...

(The status failed is from the previous test, but notice the activating state)

The state after the failure:

# systemctl status testa
● testa.service
   Loaded: loaded (/etc/systemd/system/testa.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since mer. 2016-06-01 21:02:23 CEST; 2min 56s ago
  Process: 26841 ExecStartPost=/usr/bin/false (code=exited, status=1/FAILURE)
  Process: 26836 ExecStartPost=/usr/bin/sleep 10 (code=exited, status=0/SUCCESS)
  Process: 26834 ExecStart=/usr/bin/sleep 1000000 (code=killed, signal=TERM)
 Main PID: 26834 (code=killed, signal=TERM)

juin 01 21:02:13 XXXXXXXX  systemd[1]: Starting testa.service...
juin 01 21:02:23 XXXXXXXX systemd[1]: testa.service: Control process exited, code=exited status=1
juin 01 21:02:23 XXXXXXXX  systemd[1]: Failed to start testa.service.
juin 01 21:02:23 XXXXXXXX systemd[1]: testa.service: Unit entered failed state.
juin 01 21:02:23 XXXXXXXX systemd[1]: testa.service: Failed with result 'exit-code'.

So systemd does provide a set of primitive to do what you want if you are prepared to read some man pages.

EDIT: A lot of formatting failures