Systemd programming, 30 months later

Posted Sep 29, 2016 16:03 UTC (Thu) by drag (guest, #31333)
In reply to: Systemd programming, 30 months later by bandrami
Parent article: Systemd programming, 30 months later

> I mean, seriously: people act like this is some kind of arcane dark art for reasons that still elude me.

It's always been trivial if you can have make a huge amount of assumptions about your environment, have a static environment, are dealing with perfectly behaving software, and are the only person that will ever need to use or maintain these systems.

When everything is simple and predictable then the simple is trivial.

The more reality diverges from the 'simple case' the more of a 'arcane art' it becomes.

Lets look at your example:

mount /A
Bctl start
mount /C
mount -a

Ok, mount /A has been mounted for a long time. Needs to do fsck check. How are the other services in your system going to deal with having that file system, btctl start, mount /C and mount -a not running for another 15 minutes or so after start up? Nothing started before it will ever be in any danger of timing out. You are also completely fine with having a inaccessible system if it runs, say, before sshd does?

Brtl start to mount /C... Are you absolutely sure there is no race condition there?

If 'mount /C' depends on a service started by 'Bctl start' and 'Bctl' does the daemon double fork then there is no way this script actually takes into account the fact that 'mount /C' is going to be ran LONG before 'Bctl' ever completes it's initialization in a fast system. May work just fine in a VM or something, but it's very likely to fail randomly. so on and so forth. Unless the 'Bctl' script contains a lot of logic itself so that it does not exit before B is started... which in that case you are just hiding the bulk of your example behind a secret-perfect command.

Basically your example pretty much going to fail in even trivial use cases.

When I do something I try to take the time to do it right the first time so I never have to deal with it again. This is definitely not something that I would find remotely acceptable except in simple one-off cases.

I've also written plenty of Init scripts and because of that I really would like to avoid doing such things.

Systemd programming, 30 months later

Posted Sep 29, 2016 17:30 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (2 responses)

> If 'mount /C' depends on a service started by 'Bctl start' and 'Bctl' does the daemon double fork then there is no way this script actually takes into account the fact that 'mount /C' is going to be ran LONG before 'Bctl' ever completes it's initialization in a fast system.

If 'Bctl' is written incorrectly, that is. Not that there aren't plenty of examples of such incorrect behavior, but the right approach would be first to complete the initialization, *then* to fork. The initial process shouldn't exit until the daemon is ready to deal with clients. (Note that systemd also requires this behavior from Type=forking services to support proper dependency handling. The service will be considered ready for use as soon as the initial process exits.)

I do completely agree with you about the other limitations of hand-written, system-specific init scripts. In practice systemd unit files are superior in every significant way, though they do require a certain amount of retraining.

Systemd programming, 30 months later

Posted Sep 29, 2016 21:43 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

> If 'Bctl' is written incorrectly, that is.

Exactly. Effectively he moved the difficulty of dealing with the sequence of these commands out of the example script and into the 'brctl' and 'mount' commands. There is no escaping the complex logic required to do these things correctly.

Systemd programming, 30 months later

Posted Oct 7, 2016 18:46 UTC (Fri) by lsl (subscriber, #86508) [Link]

That logic needs to be in the B service, one way or another. Only the service itself can know when it considers itself ready for operation, so it is going to signal that readiness by exiting from the parent, starting to accept connections from a socket, signaling an eventfd or something entirely else. Whatever the mechanism, the underlying logic needs to be there.

The nice thing about socket activation (as implemented by systemd) is that it can piggyback on a mechanism we're probably using anyway as part of normal operation and for which the kernel already does lots of the ordering orchestration. It might not fit all services but when it does it's a very nice thing to have.