On 27 August 2016 at 09:37, Jonathan de Boyne Pollard
Post by Jonathan de Boyne PollardPost by Adrian ChaddSure, but I'm looking for something more generic than just devd. Like,
notifications about events like "default route is up" can be done by
sniffing the rtsock, but notifications like "ntpdate has updated the date,
we can now do crypto services" doesn't happen there right now.
You're reinventing upstart. The lesson of upstart is that whilst the
event-driven paradigm looks like the bright shiny future, once one gets down
to the details it is a lot harder than it at first appears. I strongly
recommended learning about upstart, and especially learning the problems
that people hit with it, to anyone going down the same route. The Debian
systemd Hoo-Hah had some lengthy discussion of upstart.
Oh yeah, I'm aware of the differences between systemd and upstart.
Post by Jonathan de Boyne Pollard(I regret not having bookmarked the discussion that I once came across,
where someone opined that xe preferred systemd to upstart because at a Linux
conference the systemd presentation had been exciting and had been put
forward as the wave of the future, where upstart had been presented as
old-school, traditional, and boring. Ironically, this person wasn't aware
that the designs are exactly the opposite of that. upstart has the novel
event-driven design where the system is configured with the information that
event A triggers programs P, Q, and R, and the system starts by raising a
"first event", that runs programs, that raise further events, that run
further programs. Whereas it is systemd that has the conventional design,
shared by Mewburn rc and others, of starting from a goal, working through a
dependency tree, and doing topological sorts.)
For some environments (servers, desktop environments, etc) where most
of the dynamicness comes from "which user is logged in" and "maybe I
don't have my network hardware plugged in until later", sure, I can
see that the dependency tree model works great. Your aim is some
grander set of checkpoints, like "What do I need to run basic network
services", "What do i need up to run a desktop login environment",
etc.
But for things like "I'm a vpn server, and I need to speak to a vpn
server to provide access to my vpn clients, oh and I have firewall
rules that need applying based on which dynamic interfaces come/go" it
still maps to an event driven mechanism. Sure you can map that event
driven mechanism to a set of targets, but those targets may be
per-interface. Like, when a vpn client interface comes up, I have a
set of things that need to happen that depend upon which client. Same
with wireless clients associating. I may hit some situations (eg above
a certain threshold of associated clients) where I trigger events such
as "clean up old clients", "look at migrating clients to other access
points", etc.
If I can do this with s6, then cool - please let me know how and I'll
re-consider it. But regardless of that, I also do need some
generalised dbus style mechanism so all the pieces of the system can
talk to the other pieces of the system without having to .. well, wrap
it all in 'service' style shell scripts and calling ifconfig wlanX
list sta periodically from everywhere.
Post by Jonathan de Boyne PollardThe Debian people chose to improve a non-event-driven architecture instead.
It's a lesson to be learned from SMF, in fact. One can have a lot more
additional abstract targets, such as "/milestone/name-services" and
"/milestone/system-clock", and dependencies to and from them. The world is
not 2 to 4 run levels plus "DAEMON", "NETWORKING", and "$local-fs".
That said, something like this hypothetical "/milestone/system-clock" is a
milestone that would need to be reached *very* early on in the bootstrap
process. Fixing up the clock is something that both the nosh system manager
and systemd handle themselves directly, outwith of service management. More
on this in a moment.
So, this is where it gets exciting in some of these appliances.
Sometimes there's no 'date/time' RTC hardware. Sometimes, you have to
present some UI to the user so they can enter a date/time, and some
services need to run before that, but some services (notably ntpdate)
won't work. So we can't, say, hold all network services back until we
have valid date/time or a bunch of the UI infrastructure won't be
there.
I can't expect the whole system to stop waiting for a system-clock
time to be valid. In fact, i ended up adding some stuff to our
appliance images that store the current clock value in a file every 15
minutes - the rootfs is read-only, so i can't just boot up from /its/
concept of "last mounted", as that filesystem is not modifiable.
Trouble is, that gets read from the system during boot, after FSes
have been mounted, etc. It's all terrible.
Thanks,
-adrian