Subject: Re: Starting and stopping servers
From: wesley.craig@umich.edu
Date: Tue Feb 22 1994 - 19:18:43 EST
> From: Jos van Wezel <wezel@bio.vu.nl>
> To: netatalk-admins@umich.edu
> Ar question which may be of interest to all. How do I stop and start afpd
> servers. (SunOS 4.1.3, netatalk 1.3b3)
You should upgrade your netatalk to the 1.3 release. There were
serious bugs in the beta you're running.
> Currently I'm running rc.atalk at boot time. In rc.atalk there is a list
> of about 9 servers putting themselves in 5 different zones. This works
> troublesome. Seemingly random picked from the list of the startup commands
> some do not result in a running afpd. So I go back and start them by hand.
> Then it mostly works. There is no 'Can't register ...' message in those cases.
At a guess, atalkd doesn't yet have a complete list of zones, when
you're trying to start your afpd's. The afpd's that are started in
zones that are local come up, the others don't. I'm not sure why you
would not be getting the "Can't register ..." message.
> Also when I want to stop servers I do a kill -TERM of the pid followed by
> a nbpunrgstr. Now sometimes I have to repeat the nbpunrgstr command several
> times before it returns with 'Can't unregister ...'.
Just in general, you should not need to do an nbpunrgstr. The TERM
signal to afpd should cause it to unregister itself.
> Are there any timeouts involved? I tried sleeping for 10 secs between several
> afpd startups. Do I need to HUP/USR[12] atalkd? Is there any recipe for
> a reliable start/stop script.
For starting in all those zones, I think I might suggest "priming"
atalkd, by adding a "-zone" for each of the zones you want to register
in. This way, even tho atalkd isn't quite stable, it will have an idea
of what all the zones are. Assuming atalkd's ready, you should be able
to start the afpd's with not sleeping.
For stopping afpd, the nicest way is to send a HUP signal, allowing the
server to notify all of its client that it will be going away, and
then, 10 minutes later, send a TERM signal. This will tell the clients
that the server has gone away, and actually kill the server.
Pretty much any deviation from this behavior by atalkd or afpd is a
bug, which we will fix.
:wes
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:20:51 EST