Apparently Cooper <Cooper@Linuxfan.com> wrote:
> Okay, alternative approach.
> Open+lock passwd, read passwd, update data, write passwd.new, rename
> passwd.new to passwd, close locked passwd.
Here's some (ugly) psuedo-code:
if open(...O_EXCL) (lockfile)
open pwfile (RO)
read/verify pw
open newpw (WR)
update/copy (old to new) --- this is a filtering operation
close newpw
close pwfile
mv pwfile to pw.old
mv newpw to pwfile
(build new hash tables if nsswitch.conf has db enable?)
(push these out if they are NIS/NIS+ maps or ???)
else
open lock file
read PID
check process status of PID
if (not it's alive)
remove stale lockfile
continue (go back to top)
else
???
> The trick here is that you can't wait for the passwd file to become
> available to you because once the lock is cleared, the file the lock was
> on nolonger exists, so you'll have to resort to polling.
> Since the passwd and shadow files don't get updated all that much by
> multiple sources at the same time it might be a workable solution, but I
> might just be (wrongly) assuming a small site with the initial
> assumption about the amount of updates.
> Cooper
What locking API are you using?
It seems like the suite of password/group file update utilities
({user,group}{add,mod,del} and chfn, passwd, et al) could use
UUCP style lock files (files under /var/lock/shadow/ containing
the PID of the process which currently holds a lock).
However, I still wonder what a process should do when it has
failed to get the lock?
I've wondered about this before. When we try to get a lock
(using UNIX local file semantics) and we fail, how do we know
when to retry. I wonder if it makes sense for programs participating
in locking to open the file (read-only) and do a select() (or poll()?)
on it.
This would require that the process holding the lock append something
to it prior to removing it. That would effectively notify all
waiting processes to wake up and compete for the new lock.
Does that make sense? Do any of the existing program suites using
lock files implement this mechanism? It still seems more efficient
than polling.
(Note: I'm not a programmer, and I don't play one on the net.
I just do a bit of scripting here and there).
--
Jim Dennis Technical Research Analyst Linuxcare, Inc.
jimd@linuxcare.com, http://www.linuxcare.com/
415 505-9306 415 701-7457 fax
Linuxcare: Support for the Revolution
