create new tag
, view all tags

Suggestion: get rid of RCS strict locking mode


I got also bitten by this problem at my company's wiki: after an apache restart (apache on debian linux), apache thinks he is somebody else for rsc locking purposes (root, myself, others...) although the process actually belongs to UID "nobody" and creating files with rcs with a dummy cgi scripts locks them with the "nobody" UID as it should.

Update: this seemed to only happen while using mod_perl, this may be the explanation -- ColasNahaboo - 14 Nov 2001

Update: I can also confirm I only got this problem after switching to mod_perl. See below for what I did. I do not recommend removing strict locking just for this issue -- KevinTam - 25 May 2004

Update: ci -u creates a strict locked file (the first time) with RCS 5.7, i.e. when creating a topic and there is no previous ,v. Strict locking works; non-strict just plain doesn't work. There was a bug in the unlock-then-try-again code in the latest RcsWrap.pm. ($cmd was overwritten with a $my cmd for the unlock command, fix was to rename the variable so the checkin $cmd wasn't shadowed)

-- JonathanGraehl - 24 Feb 2005

Thinking of it, I wondered why TWiki is using strict locking anyways,as:

  • TWiki is the only one checking in revisions (and the only one that can do it, as files actually belongs to it)
  • TWiki has its own locking mecanism (.lock files)
  • This would get rid of all the problems moving data files between wiki engines running under different IDs (nobody uid is not the same on all machines, debian uses www-data...), and installation.
  • And ease sharing the same data files via different engines for "load balancing" or access control purposes


So I have done it, and it works quite well (Sep 2001 version):

  1. Convert your existing TWiki data to non-strict locking, and unlock the files. (This should also be done for the TWiki distribution of course) In your TWiki dir, run:
    1. rcs -U -u -M -q  `find . -name \*,v`
      Unlocks the existing RCS files, and put them in non-locking mode
    2. chmod u+rw `find . -name \*.txt`
      Enable write on the topic files. They were read-only in locking mode
  2. In your lib/TWiki.cfg config file:
    1. add the -U option to $revInitBinaryCmd
      This will made the default mode of non-locking (may not be needed)
    2. change all the -l options to -u in all the $revXXX variables (4 occurences)
      This makes TWiki stores revisions in non-locking mode
  3. In the lib/TWiki/Store.pm:
    1. in sub saveFile, add just before the line with open:
      chmod(0644, $name);    # for non-strict locking
      Makes TWiki change topic file mode to writable before trying to write
    2. in sub saveAttachment, add just before the line with copy:
      chmod(0644, $newFile);    # for non-strict locking
      Same for attachements

Voila! no more unexpected locking problems that can seriously annoy users...

I strongly suggest that this change be made in the TWiki distrib.

-- ColasNahaboo - 30 Oct 2001

I agree - it would have made my life easier if this was not the case.

-- MartinCleaver - 31 Oct 2001

Hm, funny that... Ever since moving TWiki to mod_perl on my Linux-box, I've seen weird locking errors appear. Apache runs as apache:apache, and rcs is launched as a child of apache, but it still tries to lock files as 'frank' or 'root', dependent on how it was started (straight console login as root -> start apache -> rcs tries to lock as 'root', BUT login as 'frank' and then su to 'root' -> start apache -> rcs tries to lock as 'frank'...).

A bit of fiddling with the environment turned up the fact that (on systems with 'secure' getlogin) rcs uses the $LOGNAME env var to obtain the lock name. A dive in the source proves this. Sooo...... just set that var (and $USER as well, rcs also likes these two to be the same, see rcs-5.x/src/rcsutil.c and grep for USER and LOGNAME).

Just put these settings in your rc-script, /etc/sysconfig/apache file or whatever your system uses, and you should be fine. If, for example, your system uses the /etc/sysconfig/apache file for apache-soecific settings, and apache runs as user apache:apache, add these two lines to /etc/sysconfig/apache:


As there might be files locked by the 'wrong' user in the tree, I'd also suggest doing something like this:

USER=apache LOGNAME=apache find /TWiki/root/dir -type f -name \*,v -exec rcs -M -u -q {} \;
USER=apache LOGNAME=apache find /TWiki/root/dir -type f -name \*,v -exec rcs -l -q {} \;
find . -type f -name \*,v -exec chown apache:apache {} \;

(this works with a Bourne-compatible shell and GNU find, YMMV)

This should unlock all files, and then relock them using the right name.

Now restart apache, and all should be well even when using mod_perl. I use it, and for me it works. So there's no need to disable strict locking...

-- FrankDeLange - 22 Nov 2001

Thanks for the tip!
I my debian linuxes, I had to add it to /etc/init.d/apache

However, I feel that my other points still justify the patch, especially when managing many wikis and moving data between them.

-- ColasNahaboo - 23 Nov 2001

I think I have found a good solution:

  • keep strict locking, as non-strict locking still fails in some cases, when resetting the lock set by another user, and adding the extra convolutions to fix it is not worth it.
    • Can you elaborate on this? StrictLocking keeps causing problems, but what are the benefits? -- ToddJonker
    • well, RCS is really designed to work in strict locking mode. I found out that I had to call not ci directly, but a script doing a lock of the last version, ( rcs -l ), then the ci, then an unlock ( rcs -u )of the version. -- ColasNahaboo - 14 Dec 2001
  • make TWiki itself set these environment vars, not relying on apache, thus:
    • it will work in all cases
    • it will work on all web servers, since the problem is RCS-related (it is RCS that uses these variables), and not server-related.
Thus I reverted to strict locking with the following modifications:

In first section of lib/TWiki.cfg, add: (replace nobody by www-data, www...)

#                   User name of the web server (for RCS)
$serverUID        = "nobody";
In In lib/TWiki.pm,
  • at the end of the use vars qw, add: $serverUID
  • in initialize, before # Make %ENV safer for CGI (line 154) add:

    $ENV{'USER'} = $serverUID;
    $ENV{'LOGNAME'} = $serverUID;

-- ColasNahaboo - 05 Dec 2001

I just ran into the same problem trying to get a new TWiki installation running. Is there any reason why these changes shouldn't be moved into the main codeline?

-- ScottGargash - 17 Jun 2003

Hmm, I thought I had it working following these instructions, but apparently it's still broken.

For whatever reason, on my system (RedHat 9/Apache 2.0.40/mod_perl 1.99.007) I've had to do some extra work to get mod_perl going. I had to add a PerlRequire directive to httpd.conf that sources a startup file that

  • adds the absolute paths to the twiki/bin and twiki/lib directories to the lib path
  • and sets the USER and LOGNAME environment variables to "apache"

Setting the USER and LOGNAME envars in TWiki.pm seemed to happen too late. RCS locking now (again) seems to be working, although I'm still having some other wierd prolems with mod_perl, so I'm still not sure everything is completely kosher.

-- ScottGargash - 24 Jun 2003

I ran into this issue after switching to mod_perl and creating a new web. To prevent this:

  • I added $ENV{'USER'} = "apache"; and $ENV{'LOGNAME'} = "apache"; to my apache startup script (startup.pl)
To fix the problems
  • I chown'd all data files back to apache (or nobody depending on your setup) where some were root
  • Removed locks on all files. (Causing an unlock using previous comments would work too)
-- KevinTam - 25 May 2004

This has been done for DevelopBranch - see KeepRcsFilesUnlocked

-- CrawfordCurrie - 17 Feb 2005

Changes to this document

Category: TWikiPatches
Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2006-01-02 - FranzJosefSilli
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.