Date: Thu, 26 Feb 1998 01:13:34 +0100 (MET) From: Stefan Bethke <stb@transit.hanse.de> To: John Fieber <jfieber@indiana.edu> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, dannyman <dannyman@sasquatch.dannyland.org>, ports@FreeBSD.ORG Subject: Re: patch for netatalk on -current Message-ID: <Pine.BSF.3.91.980226010245.24177A-100000@transit.hanse.de> In-Reply-To: <Pine.BSF.3.96.980225175839.3416H-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 1998, John Fieber wrote: > On Wed, 25 Feb 1998, Jordan K. Hubbard wrote: > > > Hmmm. Maybe I was just being impatient and didn't give it long > > enough, but does it *ever* background itself? If not that's kinda > > bogus since you'll never get to anything else in the startup > > sequence. :) > > Yes it does background itself. It can take awhile, particularly > on a big network. It takes over a minute for me since my > appletalk network covers the entire Indiana University system > (~95,000 students statewide). Atalkd installs on the order of > 600 routes when it starts. The whole netatalk process could be > backgrounded, so long as the pieces go in the correct sequence. Actually, atalkd is starting first, and all other services need it. Atalkd needs about 30 seconds for each configured interface to start up. This is definitly a point for debate. Currently, I have made the decision to wait for atalkd to start up before doing anything else. It is possible to start atalkd in the background, but it will give you errors only in the background. This is useful for a development machine, but not necessarily for production use, where you want basic errors to pop up as early as possible. You might consider atalkd the same as the basic ifconfig's for the IP configuration, and if these would fail, I presume, you would want to know about it immediatly, instead of looking afterwards after /var/log/messages (or whatever). However, the main point about these changes are for me, whether they break 2.2.6 or keep it working. If someone running current has to adjust manually for this port, I'd find that acceptable, if it works seemlessly for the 2.2.6 case. I am willing to suspend this commit until after the ports and packages are built for the 2.2.6 CD. If you are sure this is working, I'll commit this right away. Stefan -- Stefan Bethke <stefan.bethke@hanse.de> Hamburg, Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.980226010245.24177A-100000>