Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!spectrum!cameron
From: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Newsgroups: comp.sys.apollo
Subject: reducing the delay between edrgy and getpwuid() etc ...
Message-ID: <1093@usage.csd.unsw.oz.au>
Date: 18 Feb 91 09:51:41 GMT
Sender: news@usage.csd.unsw.oz.au
Reply-To: cameron@spectrum.cs.unsw.oz.au
Organization: EECF, Dept of Comp Sci & Eng, Uni of USW, Sydney, Australia
Lines: 27

I have some home-grown software here we use for maintaining accounts. We have
several hundred students all requiring account each session, and thus the
interactive make-an-account-by-hand-with-edrgy approach is out, thus this
code. It basicly opens a few pipes and talks to edrgy and provides a function
call interface.

My problem is currently that after I've called the make-an-account call, and
edrgy's replied with a prompt indicating all is happiness, I often won't be
able to successfully do a getpwuid() or getpwnam() on said account for quite
a while (typically about a minute). Currently I sit in a loop polling
getpwuid() and sleeping for 10 seconds until it works, so that the program
can continue on its way and make home directories and set ownership, etc.

What I'd like is to learn of some way to poke the registry daemons (or the
mechanism getpwuid() uses) to reduce this delay as much as possible. Saying
`synch' to the local registry via edrgy has no obvious effect. Any ideas?
	- Cameron Simpson
	  cameron@spectrum.cs.unsw.oz.au

P.S.	Currently I'm contemplating mad schemes involving yet-another-child
	process which hadles a queue of pending new accounts which does the
	propagation waiting for me, and follows up with the chown stuff when
	it can, or inline queues which get polled at convenient spots to see
	if the new uid has propagated, etc. None of them are very nice.
--
"I guess this is what you get for being on the leading edge,
 you get cut sometimes."	- Douglas Rand