> -----Original Message-----
> From: Rich Fernandez [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 2:23 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: flock problem on AIX 4.3.3
>
>
> Hello,
>
> A colleague is experiencing some problems using user_manage
> v1.53 by Lincoln
> Stein with
> Apache Stronghold 3 on AIX 4.3.3. Seems as though the entire
> password file
> is getting
> corrupted when there are a lot of people changing passwords.
> The file seems
> to be blanked
> out and/or with only a few entries. We are using flat files and not a
> database.
>
> We wrote to Lincoln and he provided us with a script which
> pointed us to a
> problem with our
> version of flock, so we rebuilt Perl with the -Ud_flock
> option to configure
> which,
> according to the doco, causes perl to not use flock and
> instead use fcntl.
>
> However the problem persists. We re-ran the test script and
> again "obtained
> lock and
> shouldn't have".
>
> Can anyone point us in the right direction?
> Please let me know if I need to provide more details.
> Thanks!
>
> --Rich
>
> The test script by L. Stein is quoted below:
>
> #!/usr/bin/perl
>
> use Fcntl qw(:flock);
> open FOO,(">./foo.lock") or die "Can't open for writing";
> flock(FOO,LOCK_EX) or die "Can't flock for writing";
> print FOO "locked\n";
>
> open BAR,"./foo.lock" or die "Can't open for reading";
> eval {
> local $SIG{ALRM} = sub { die "timed out\n" };
> alarm(5);
> flock(BAR,LOCK_SH) or die "Can't flock for reading";
> };
> alarm(0);
>
> if ($@ =~ /timed out/) {
> print "timed out as expected\n";
> } else {
> print "obtained lock and shouldn't have\n";
> }
This program prints "obtained lock and shouldn't have" on my HP-UX 11.0
system as well. I think the problem is with POSIX lock semantics. On my
system, flock is implemented using fcntl(2). A section from my fcntl(2)
manpage says:
"Locking a segment already locked by the calling process causes
the old lock type to be removed and the new lock type to take
effect. All locks associated with a file for a given process are
removed when a file descriptor for that file is closed by that
process or the process holding that file descriptor terminates."
I ran into a simlar (though not identical) problem trying to get the
module Tie::DB_FileLock to work. This module would dup the dbm handle,
lock the dup'ed handle, then close and reopen the other handle to get
changes to the buffers, assuming the lock still held. This simply would
not work on a POSIX system, due to the semantics above.
HTH.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
