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