Jump to content


Photo
- - - - -

Record Locked


11 replies to this topic

#1 hath

hath

    Member

  • Members
  • PipPip
  • 17 posts
  • Gender:Male

Posted 04 January 2005 - 12:15 AM

I have a proisam file which was locked on a particular record due to a crash (core file dump) on the function which updates the file.

Although I have ensured that all dead sessions have been terminated, the next day I 've tried to update on the same record, it is still locked. What I could do to clear the locking is exporting out the records in the file, recreate the file, then importing the records back in. But this should only be the last option.

Does anyone know how to look for the locking and clear it ? There must be some kind of a defunct function still memorised somewhere.

Thanks.

#2 Brian Manners

Brian Manners

    Member

  • Members
  • PipPip
  • 46 posts
  • Gender:Male
  • Location:Melbourne

Posted 04 January 2005 - 03:54 AM

Are you in a position to allow a full server reboot?
It's all good

#3 Ashok Prakash G

Ashok Prakash G

    Member

  • Members
  • PipPip
  • 19 posts
  • Gender:Male
  • Location:Limerick, Ireland

Posted 04 January 2005 - 06:44 AM

Are you in a position to allow a full server reboot?

Yes as per Brian If you can reboot the Server then all the locks will be released.

#4 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 04 January 2005 - 09:16 AM

Hi,

You shouldn’t need a reboot.

You can try to use the ProIV isview util to find the process that has the record lock, and kill that process.

Do not try to 'recreate' the file while there is a record lock, this will probably create a 'corrupt' file. ProISAM has a problem recreating files that have open record locks... or at least it used to.

Have you made sure that the iscollect process is running? This is the process that clears up record locks when processes die unexpectedly.

Another possibility....

Have you made sure that all 'pro' processes are removed? Or is this not possible? (maybe its a 24/7 system).

If all processes are killed, then you can kill iscollect and then use the unix ipcrm command to remove shared memory and semaphores. This should reset ProISAM record locks for you and release any rogue locks.

Once you restart ProIV, make sure that iscollect starts automatically... it should. If not, then you may have a problem with your setup.

Rob D.

#5 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 04 January 2005 - 02:17 PM

Hath,

There is also a very ugly way to do this - in unix.

If you look at isview, any thing that has a value other than zero is a record lock.

2007eaa 0/1 0 59ec: 8783 4 1/c 5a04
5cc0: 2291 4 1/a8 5cd8
4ce0: 16994 4 1/0 4cf8
4d68: 17056 4 1/18 4d80
4df0: 17118 4 1/24 4e70
4ee0: 17361 4 1/30 4ef8
507c: 17370 4 1/3c 5094
52ec: 17380 4 1/48 5304
4f68: 17441 4 1/54 4f80
4f90: 17501 4 1/60 4ff0
4e20: 17562 4 1/6c 513c
5de0: 17623 4 1/78 5df8
53f0: 17683 4 1/84 5408

This is an example output of isview. 2007eea is a reference to the file being locked. eea represent the hex value of the inode of the file in question. The column that includes 17683 and similar numbers is the process ID column.

Assuming you have only one lock, you could simply kill that process.

...

One option other than rebooting:

Unix: Kill all pro processes and then kill iscollect.
Windows: Restart the service

hth,

Joseph

#6 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 04 January 2005 - 02:38 PM

This is an example output of isview. 2007eea is a reference to the file being locked. eea represent the hex value of the inode of the file in question.

Just to add to that, regarding inode numbers. In the directory containing the file in question: ls -li filename.pro (that's ell ess minus ell eye) will show you the inode number in decimal in the first column.


Unsure off the top of my head if there's a way to get the inode number in hex.

#7 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 04 January 2005 - 09:46 PM

Rick,

Unsure off the top of my head if there's a way to get the inode number in hex.


Unfortunately, I've always used the hex function on my calculator when it comes down to that. :)

isview is a solution we tend to avoid because it is a very costly way to isolate a record lock.

Regards,

Joseph

#8 hath

hath

    Member

  • Members
  • PipPip
  • 17 posts
  • Gender:Male

Posted 05 January 2005 - 10:12 PM

I think the problem I 'm having now is 'iscollect' not running. We're doing a ProIV conversion from 4.5 to 5.5 and creating a new ProIV environment on a new hardware.

I 've checked if 'iscollect' is running by running 'ps -ef | grep iscollect' command on Unix and it is not found. How does 'iscollect' get started automatically ? Initiated as part of server reboot ?

Thanks.

Hath.

#9 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 05 January 2005 - 10:29 PM

Hath,

make sure that iscollect has the sticky bit turned on.

ls -l iscollect should look something like

-rwsr-xr-x 1 root bin 57453 Jul 19 2001 iscollect

If yours does not include include the s, type chmod +s iscollect

iscollect is called automatically the first time that pro is run. The s bit makes it run as a service and should ensure that only one instance is running.

If the permissions are wrong, or the s bit is not set, bad things happen.

hth,

Joseph

#10 hath

hath

    Member

  • Members
  • PipPip
  • 17 posts
  • Gender:Male

Posted 05 January 2005 - 10:53 PM

Thank you all for valuable hints and tips ...

I have resolved the problem. It was 'iscollect' not started automatically because there was no 'iscollect', but 'iscollect_64' which is what was provided by the PROIV installation.

Cheers.

Hath.

#11 Guest_guest 23_*

Guest_guest 23_*
  • Guests

Posted 06 January 2005 - 12:38 PM

ls -l iscollect should look something like

-rwsr-xr-x 1 root bin 57453 Jul 19 2001 iscollect


iscollect is called automatically the first time that pro is run. The s bit makes it run as a service and should ensure that only one instance is running.

Run as a service?

No. And this does nothing to prevent 2 instances running (I think a lock file is used for that).


the sticky bit means the process will start with group/owner
as that of the iscollect file owner (i.e. root) and not the group/owner that executes iscollect
(i.e. some p4 user).

HTH

#12 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 06 January 2005 - 06:50 PM

No. And this does nothing to prevent 2 instances running (I think a lock file is used for that).


I happily exercise my right to be wrong and learn from someone with more knowledge. :)



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users