1 |
On Sun, Aug 28, 2016 at 11:29 AM, Patrick Lauer <patrick@g.o> wrote: |
2 |
> |
3 |
> (and what abuse? it did exactly what it was supposed to do quite nicely, |
4 |
> until it stopped doing that. Now you need to track state and hope you |
5 |
> don't have race conditions ... ) |
6 |
> |
7 |
|
8 |
You were tracking state before; in mtab. It just isn't a terribly |
9 |
great way to track state, especially when you start getting into |
10 |
complex situations. What happens when a service depends on a fuse |
11 |
filesystem, which depends on a service? And of course all the |
12 |
situations where it is wrong, like when it is mounted read-only. |
13 |
|
14 |
In the past we had kludges like iteration - try to unmount stuff, kill |
15 |
stuff, and then try harder until it all dies, and then mount read-only |
16 |
whatever got missed. In theory today you can actually get messy |
17 |
situations to cleanly shut down as long as you specify your |
18 |
dependencies correctly (which you also need to start it all up). |
19 |
|
20 |
I get that you can run a lot of systems without all the |
21 |
complexity/rigor, but then you're pitting your ability to write |
22 |
bug-free simple scripts against Redhat's ability to do QA on complex |
23 |
scripts. Sure, we aren't beholden to them, but half the point of FOSS |
24 |
is to borrow stuff that works. |
25 |
|
26 |
-- |
27 |
Rich |