[279] in Athena_Backup_System
slave re-registration protocol
daemon@ATHENA.MIT.EDU (delgado@MIT.EDU)
Thu Jun 27 20:50:01 1996
From: delgado@MIT.EDU
To: athena-backup@MIT.EDU
Date: Thu, 27 Jun 1996 20:49:53 EDT
Here is a summary of the change of master protocol with the
modifications necessary to support the crippled mode master.
(discussed at today's meeting.) Please read it to determine
if this makes sense.
1. Admin makes change to slave config file
2. Admin issues kill -HUP to slave
3. Slave catches HUP signal and re-reads is config file
noticing that the info for th master's host has changed.
4. Slave changes its internal info (a global variable) which
keeps track of the name of the master's host.
5. Slave issues a abs_register_device to the Master.
If the slave is not running any jobs, it will supply
a NULL job information pointer as a parameter of this call.
If the slave is running a job, it will create a
job_res_structure using its current job info and
pass this as part of the abs_register_device call.
6. Normal master will look at the job info pointer, and
if null, will delete any job info which might exist for
that slave and update the slave's registration info.
the Master can use the info supplied in the job_res
structure to re-construct job info that might be missing,
e.g., because the job was started in crippled mode.
Crippled mode master will store the job info if it's
not null and the registration info for the slave.
Changes to the ABS_SLAVESERVICE interface
int
abs_register_device(slave_info_pt, job_res_pt);
^^new parameter
Changes to Slave:
HUP Signal handler now has to register the slave with new master.
Need to block HUP in critical code sections of Slave
because this signal handler is now more disruptive than
previoulsy. (Critical code sections are those where
we don't feel comfortable interrupting a task to
send a abs_register_device RPC call e.g., during
AFS RX volume dump/restore calls or code which is not
re-entrant).
