4 ms·
Personally, I hate not being able to dig into it when something goes wrong. But that familiarity will come with time. What I absolutely LOVE is a much more ro
by arbitrage 11y ago
Personally, I hate not being able to dig into it when something goes wrong. But that familiarity will come with time.
What I absolutely LOVE is a much more robust ordering of system service turn ons. Start network BEFORE ntpd. Start rpcbind BEFORE nfs-server. A lot of hack solutions for this chicken & egg problem in the past were always very fragile.
- vezzy-fnord 11y agoFYI, all ordering options in systemd are relative and not absolute. You cannot guarantee in systemd that X will be started before Y, because that's not how it works. You declare an approximate dependency and ordering scheme, which is then fed into a graph, optimized and recalculated in memory on every bootup and state-modifying operation. There is no determinism in the boot order due to parallelism and some other constraints, so you can potentially have services be malignantly reordered or fail because of cyclical transactions, loops and stuck jobs. The point is that, if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way.
- deleted 11y ago[deleted]
- simoncion 11y ago> if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way. Are you sure that OpenRC works in this way? There may be some subtlety that I'm missing, but the documentation for systemd unit files [0] seems to describe a service dependency and ordering specification system that looks equivalent to what OpenRC provides with "need", "use", "before", and "after". (Search for "[Unit] Section Options" and read on from there.) [0] http://www.freedesktop.org/software/systemd/man/systemd.unit.html http://www.freedesktop.org/software/systemd/man/systemd.unit...
- vezzy-fnord 11y agoAgain, don't be deceived into judging an architecture by its public interface. It certainly appears similarly, but the dependency and ordering primitives are interpreted much more loosely like tags than they are like absolute requirements. Simplifying things, your unit file actually becomes a Unit object which queues a job (which is itself a Unit) which is scheduled and checked for consistency in a transaction, which encapsulates a service (itself a Unit and one that controls jobs). The final graph of dependency information largely does not reflect what you configured.
- simoncion 11y ago> It certainly appears similarly, but the dependency and ordering primitives are interpreted much more loosely like tags than they are like absolute requirements. Ah. That would be the "subtlety" that I was missing. Thanks! :) As an aside: how terrible it is to provide an interface that makes it look it gives you ordering guarantees when -in actuality- it gives you no such thing! :(
- vezzy-fnord 11y agoWell, in fairness, the developers are honest about it. But they perhaps do not make it as obvious they should, and a lot of people are fooled (I'd cynically argue to the benefit of the systemd developers).
- pc2g4d 11y agoSo how does this work? Wouldn't ntpd sometimes start before networking, for example? Why is this not a bigger issue?