Re: piece of mind
The Wanderer dijo [Tue, Oct 21, 2014 at 11:10:41AM -0400]:
> >>> Can you give an example of people doing that in case of systemd?
> >>> Because so far, everything I heard was similar to GNOME, where:
> >>> • systemd provided a feature.
> >>
> >> This is the problem. The init system should not be providing
> >> "features" which other software might, post-boot and pre-shutdown,
> >> want to make use of.
> >
> > Define "post-boot". What about socket activation? Or starting up my
> > database when the iSCSI link to the storage comes up, instead of
> > *whenever*? Or cleanly restarting my Apache heap-of-processes?
>
> None of those things are done exclusively at boot / shutdown time, so
> they should not be done by the init system. If they are done at all,
> they should be done by something which can run and do them under any
> init system.
That's precisely the quid. We were used to having a passive init
system, and called "initialization" to the actions that happen upon
boot. All further state changes had to be monitored by, well, "state
monitoring daemons" (in a broad sense). But our computers are each
time less static than back in 1983.
That's the reason why most of us felt SysV had to be replaced with
something more adequate to our current reality. No, I'm not frankly
familiar with systemd (although I run it at two of my computers, but
I'm not yet familiar with its ways), but this argument has been
floating around for many years already.
Fact is, state changes should often alter what's running. The example
you quote states the iSCSI link should be a dependency and a trigger
for the database activation. Is the network flaky? OK, the database
should shut down if it no longer has access to its backing store. Is
the iSCSI link back up? OK, the database should start answering
queries as soon as it's available. What does it take to make it
available? Well, for starters, it should be fsck'ed, as it was
forcibly unmounted (it fell out of existence).
Why shouldn't an init system take care of such operation? After all, I
configured "I want PostgreSQL to run on the server". Isn't that
enough?
Even more: If I ask my system, "why is PostgreSQL not running?", it
should clearly tell me, "the disks where it wants to reside do not
currently exist". Or even more: if I just ask the system, "how are you
feeling today?", I should be able to see (in red, bold letters)
anything that aches.
> (...)
> That isn't all you gain by it; you also gain the benefit of being able
> to use these features no matter which init system you're running. Which
> in turn helps avoid lock-in, and enable easier testing of (or migration
> to) alternatives, and prevent user surprise, and so forth.
Yes. But it would end up finally boiling up to having your favorite
init spawning nothing but this newfangled ultra-process-supervisor,
which would then start monitoring everything. That is, you'd have
whateverinit spawn a PID 2 process, which would... Perform precisely
systemd's tasks.
Reply to: