[Interchange-bugs] [Bug 267] New - Interchange errors out on file locking

[bugzilla-daemon@interchange.redhat.com]

http://developer.akopia.com/bugs/show_bug.cgi?id=267

*** shadow/267	Tue Jul 10 00:24:48 2001
--- shadow/267.tmp.713	Tue Jul 10 00:24:48 2001
***************
*** 0 ****
--- 1,76 ----
+ Bug#: 267
+ Product: Interchange
+ Version: 4.6.5
+ Platform: HP
+ OS/Version: HP-UX
+ Status: NEW   
+ Resolution: 
+ Severity: major
+ Priority: P2
+ Component: Core
+ AssignedTo: mike@minivend.com                            
+ ReportedBy: cdc@groupz.net               
+ URL: 
+ Cc: 
+ Summary: Interchange errors out on file locking
+ 
+ On HP-UX 11.0 (perl 5.005_03) interchange 4.6.5 the file locking seems to be in 
+ error:
+ 
+ make test was failing on tests 5 and 6.  I remove the -q option from 
+ Interchange and got Permission denied errors:
+ 
+ server/inetmode.......
+ Could not lock file: Permission denied
+ server/control........
+ Could not lock file: Permission denied
+ 
+ In this case, the Permission denied occurs because the file is already locked 
+ by another process.
+ 
+ In tracing out the code, and hacking out a bit of C, it appears like the 
+ interchange.pid file (and perhaps others) are being locked with a write lock 
+ (F_WRLCK).  A subsequent call to interchange with a parameter like stop will 
+ fail because the process cannot get an F_WRLCK on a file that's locked in any 
+ way (READ or WRITE):
+ 
+ from fcntl:
+            A read lock prevents any other process from write-locking the
+            protected area.  More than one read lock can exist for a given
+            segment of a file at a given time.  The file descriptor on which
+            a read lock is being placed must have been opened with read
+            access.
+ 
+            A write lock prevents any other process from read-locking or
+            write-locking the protected area.  Only one write lock may exist
+            for a given segment of a file at a given time.  The file
+            descriptor on which a write lock is being placed must have been
+            opened with write access.
+ 
+ The easy out is that I'm not sure you really need a lock on the pid file at 
+ all.  The more complicated problem is that I'm not sure what else is affected 
+ by the lock "problem".  Moreover, I'm not sure what the author was trying for 
+ with the locks.  It might help to know that the posix defines in Linux are 
+ different than those of HP:
+ 
+ Linux:
+ /* For posix fcntl() and `l_type' field of a `struct flock' for lockf().  */
+ #define F_RDLCK   0/* Read lock.  */
+ #define F_WRLCK   1/* Write lock.  */
+ #define F_UNLCK   2/* Remove lock.  */
+ 
+ HP:
+    /* Values for l_type used for record locking with fcntl() */
+ #  define F_RDLCK 01
+ #  define F_WRLCK 02
+ #  define F_UNLCK 03
+ 
+ BTW, HP doesn't have flock; HP does have fcntl and lockf.  Though for some 
+ reason, I thought Perl would take care of most of these problems by "making 
+ flock essentially use the fcntl semantics.
+ 
+ I wasn't able to search the posts on the message board, but I recall reading 
+ some posts where folks from other platforms (other than Linux) were 
+ experiencing similar problems.
+ 
+ Lemme know what I can do to help.