Date: Wed, 3 Feb 1999 00:27:34 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@whistle.com (Julian Elischer) Cc: wes@softweyr.com, peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG, witr@rwwa.com Subject: Re: more modular rc/init/uninit system... Message-ID: <199902030027.RAA09724@usr09.primenet.com> In-Reply-To: <Pine.BSF.4.05.9901312332270.304-100000@s204m82.isp.whistle.com> from "Julian Elischer" at Jan 31, 99 11:37:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> sounds like you arwe describing the process > that we use to control the interjet. > > all system activities are assigned dependencies, including such things as > "hostname was changed" and similar events. > If you indicate such an event the dependency graph is traversed and all > services that have such a dependency are notified or restarted. > > Of course it's very interjet specific. > > so of course it IS doable.. > but it requires a lot ofinfrastructure, and of course we are running a > very predictable environment > where we know all activities being run under freeBSD onth e Interjet, as > well as the hardware configuration. So our dependencies can be > hardcoded.. Not to let any cats out of any bags, but... This is *not* the process used to start the IJ. The IJ process is *much* more rigidly deterministic than you'd actually like in a non-simplified case. Someone has already mentioned my service dependency point in another posting in this thread. But their description is not complete. What we have are groups of of indivisible programs (programs which must run at teh same time). These indivisible programs export a "service cluster". Each "service cluster" contains one or more "services". A "service cluster" may also be made up of divisible programs. A "service" is well known, and constitutes a rendesvous point. For example, the indivisible program "sendmail" exports the service cluster "mail services" which contains the service "SMTP" and the service "LMTP". Other programs use4 these services to rendesvous with sendmail and exchange information. So far, we are on the same page that has already been covered; now lets make things complicated. I have the service "DNS" exported by the program "bind". The program "bind" may make calls to syslog(3). The syslog(3) interface depnds on the service "syslog". The service "syslog" is exported by the program "syslogd". The program "syslogd" may be configured to send information to a central management server via a dependency on the service cluster "network". The service cluster "network" is a virtual service, which means that it's an alias for a service cluster that must look like a single service. Among other services in the cluster "network" is the service "DNS". So, using the Makefile analogy: DNS: start_bind echo "DNS started" start_bind: interface_config interface_up syslog echo "BIND started" syslog: network echo "syslog started" network: interface_config interface_up DNS YP echo "network started" ...A circular dependency. So, how to convert a cyclic dependency graph into an acyclic dependency graph so that you can actually start things? You need the ability to not only specify *hard* dependencies, like bind on syslog, but also *weak* dependencies, like syslog on bind. Basically, this boils down to "NEED" vs. "WANT". The program(s) can "EXPORT" services once they have the services they "NEED", and thus satisfy dependencies. The state management software on the IJ doesn't do this. The part that gets tricky is the part about what to do when the configuration changes. You need to know if the configuration data change for a service you IMPORT (NEED/WANT) impacts the service you EXPORT. Using the DNS/syslog example, the service that the syslogd EXPORTS is a listen on port 514 and a (possible) forwarding of messages to other hosts, by name, from the /etx/syslog.conf. If the DNS changes, then, the syslogd may need to reconfigure itself. But if the syslogd reconfigures itself -- either because of a DNS change, or because the /etc/syslog.conf contents have changed -- the DNS does *not* need to reconfigure itself. That's because the service the syslogd exports is a listen on port 514, and that *didn't* change. If the data change didn't result in a different host than the one that syslogd "cached" (by virtue of connecting a UDP datagram port), then there's no need for a reconfiguration. There are also border conditions to contend with... like the /etc/hosts file, and/or modification of the "syslog" service record in /etc/services. Changes to either of these might need to signal a reconfiguration. Another editorial topic: What really happens here is that the real problem that we are dealing with is *not* reconfiguration, but the fact that there is the concept at all of cached data. Consider a host name change. If no program caches a copy of the host name, and each time the name is referenced, it is obtained from the system configuration data, why then there is no need to reconfigure programs that need to know the host name. What it boils down to is that there is no universally accessible global configuration space, and that programs cache data that they shouldn't. Basically, that's a legacy from when it was much more expensive to access the data, so it was worth taking the explicit reconfiguration hit (go offline) to get the new data instead of accessing it each time (take longer per transaction). Ah well, until everyone supports tupple spaces, ala "Linda" or "TSpaces" (download from http://www.almaden.ibm.com/cs/TSpaces/ to play with), that's the world we live in... PS: JINI is a subset of TSpaces... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902030027.RAA09724>