Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Blocker
-
Resolution: Fixed
-
Component/s: cvs-plugin
-
Labels:None
-
Environment:CentOS 5.7, cvs-1.11.22-9.el5, cvs plugin version 2.0
-
Similar Issues:
Description
Since the update to the java cvs plugin, I can't do anonymous readonly cvs update anymore. It fails with this message:
cvs update: Updating .
cvs update: failed to create lock directory for `/var/cvs' (/var/cvs/#cvs.lock): Permission denied
cvs update: failed to obtain dir lock in repository `/var/cvs'
cvs [update aborted]: read lock failed - giving up
Note: Initial checkout after cleaning workspace works, only updates don't work.
The is also another problem which may be a side effect: I see hanging around cvs server processes which only terminate after jenkins is shut down.
We are running cvs pserver from xinetd like this: cvs -f --allow-root=/var/cvs pserver
CVSROOT is ":pserver:anonymous@cvs:/var/cvs"
Anonymous readonly updates have always worked with jenkins, as well es they do with Eclipse or Netbeans.
Did I miss something?
Regards,
Simon
Attachments
Issue Links
- depends on
-
-
- Resolved
-
Activity
Simon Matter
created issue -
Simon Matter
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Priority | Major [ 3 ] | Blocker [ 1 ] |
I've tried quite a lot but just couldn't find what is wrong.
The jenkins user doesn't matter at all because we are running over the network with pserver, so directory access of the jenkins user has no effect.
The 'anonymous' user is mapped to unix user 'anoncvs' on the cvs server, which has no password in $CVSROOT/CVSROOT/passwd and is member of the unix group 'cvs', which has write access into the cvs modules directories. Of course 'anonymous' is also listed in $CVSROOT/CVSROOT/readers
Both, 'cvs' and 'anoncvs' have no write permission on directory $CVSROOT (/var/cvs), which is owned by root. The only access they have is to the subdirectories of /var/cvs. Like this:
drwxr-xr-x 5 root root 4096 Jan 31 07:18 /var/cvs
drwxrwxr-x 3 cvs cvs 4096 Feb 3 08:52 /var/cvs/CVSROOT
drwxrwxr-x 7 cvs cvs 4096 Feb 3 08:07 /var/cvs/invoca
The main question is, why does the cvs update try to create a lock for `/var/cvs' (/var/cvs/#cvs.lock) which is the repository root? That makes no sense and is not allowed.
Can it be that the problem is relatd to the new feature that multiple modules can be handled together? To me it seems that the list of directories to update from cvs also includes the repository root, which it should not.
Thanks for looking into it,
Simon
Simon Matter
added a comment - I've tried quite a lot but just couldn't find what is wrong.
The jenkins user doesn't matter at all because we are running over the network with pserver, so directory access of the jenkins user has no effect.
The 'anonymous' user is mapped to unix user 'anoncvs' on the cvs server, which has no password in $CVSROOT/CVSROOT/passwd and is member of the unix group 'cvs', which has write access into the cvs modules directories. Of course 'anonymous' is also listed in $CVSROOT/CVSROOT/readers
Both, 'cvs' and 'anoncvs' have no write permission on directory $CVSROOT (/var/cvs), which is owned by root. The only access they have is to the subdirectories of /var/cvs. Like this:
drwxr-xr-x 5 root root 4096 Jan 31 07:18 /var/cvs
drwxrwxr-x 3 cvs cvs 4096 Feb 3 08:52 /var/cvs/CVSROOT
drwxrwxr-x 7 cvs cvs 4096 Feb 3 08:07 /var/cvs/invoca
The main question is, why does the cvs update try to create a lock for `/var/cvs' (/var/cvs/#cvs.lock) which is the repository root? That makes no sense and is not allowed.
Can it be that the problem is relatd to the new feature that multiple modules can be handled together? To me it seems that the list of directories to update from cvs also includes the repository root, which it should not.
Thanks for looking into it,
Simon #cvs.lock is created in the root of the directory currently being updated on the server side (see the CVS redbook for details). JENKINS-12581 is having an effect here as the name of the module being updated is not being passed to the repository correctly so CVS is trying to create the lock file in the root of the repository rather than within a module.
| Link |
This issue depends on |
| Assignee | Michael Clarke [ mc1arke ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
Code changed in jenkins
User: Michael Clarke
Path:
src/main/java/hudson/scm/CVSSCM.java
src/main/resources/hudson/scm/CVSSCM/config.jelly
http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915
Log:
[FIXED JENKINS-753] Allows performing a clean checkout if update fails
[FIXED JENKINS-12595] CVS gets passed the module name so creates lock
files in the correct directory on the remote server
[FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate
command to prevent an attempt to checkout all remote modules
Fixed in 2.1. Caused by the checkout/update command not explicitly specifying which module to checkout which some CVS servers didn't like
| Fix Version/s | current [ 10162 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Workflow | JNJira [ 142961 ] | JNJira + In-Review [ 190362 ] |
I'm not able to replicate this, and Googling similar error message shows it seems to be a permissions error. Can you check that the user 'anonymous' and the user Jenkins is running under have write permission to the directory specified in your error (i.e. /var/cvs)?