Date: Wed, 4 Jun 2003 01:13:15 -0400 From: Mike Barcroft <mike@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root Message-ID: <20030604011315.F70533@espresso.bsdmike.org> In-Reply-To: <3EDD7CFA.4795FB99@mindspring.com>; from tlambert2@mindspring.com on Tue, Jun 03, 2003 at 10:00:42PM -0700 References: <20030602171942.GA87863@roark.gnf.org> <xzpznl02nry.fsf@flood.ping.uio.no> <20030603080456.GA57773@cirb503493.alcatel.com.au> <3EDD7CFA.4795FB99@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> writes: > Peter Jeremy wrote: > > On Mon, Jun 02, 2003 at 02:25:43PM -0700, Matthew Dillon wrote: > > > start!). Running certain daemon startups in the background might yield > > > a significant overall improvement in startup times. > > > > This isn't a definite win. I know in the past it used to actually > > slow things down: To take your example, having both sshd and sendmail > > attempting to fault-in from disk in parallel will thrash both the disk > > and cache far more than sshd and sendmail sequentially faulting in. A > > very large number of daemons trying to start in parallel will also > > stress the scheduler. > > The main problem we ran into with doing this on the InterJet > was thatsome services started later would finish starting > before earlier services on which they were dependent. > > It's not very good, for example, for sendmail to try to get > its name that it's going to use in conversations with its > peers from a DNS that's not up yet, or for it to try to log > an error about that failure to a syslogd that's not up yet, > or for cron to try to send a mail message about a job that's > just completed, but sendmail isn't up, etc.. > > People try to pretend that the dependencies that exist are > between programs, but they're actually between service > providers and service consumers, and largely independent of > the programs providing the services. On top of that, the > dependencies tend to be both hard and soft, e.g. it's possible > to continue to offer a degraded service, rather than failing > outright, if some dependent services aren't there (e.g. you > can log by IP address if DNS isn't up to provide reverse > name mappings to look pretty in your logs, etc.). I think if we identify the dependency graph we can restrict the parallelization to only the leaf nodes. Granted, we're probably missing some non-obvious dependencies in rc.d like the cron/sendmail one you mentioned. Best regards, Mike Barcroft
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030604011315.F70533>