Community
Participate
Working Groups
As reported on the cross-project mailing list, jetty, modeling/m2t/xpand and another build are not able to sign anymore the artifacts. After the outage yesterday I am having trouble signing my artifacts. The signing task times out[1] and the file /home/data/httpd/download-staging.priv/arch/signer.log remains empty. I suspect that other builds have the same issue and the file remains empty for them too [2]. In the log of the graphiti build I can see an ominous log: file group-writable. [ant] [ant] /usr/bin/sign: line 90: /opt/public/download-staging.priv/arch/signing_queue: Permission denied [ant] /usr/bin/sign: line 91: /opt/public/download-staging.priv/arch/signing_queue: Permission denied [ant] /usr/bin/sign: line 92: /opt/public/download-staging.priv/arch/signing_queue: Permission denied [ant] /usr/bin/sign: line 93: /opt/public/download-staging.priv/arch/signing_queue: Permission denied [ant] /usr/bin/sign: line 94: /opt/public/download-staging.priv/arch/signing_queue: Permission denied Also, the permissions to the /download-staging.priv/rt/jetty were not enabling hudson to write new folders there anymore. [1]https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-rt-bundles/103/console [2]https://hudson.eclipse.org/hudson/job/gmp-graphiti-nightly/663/console
It's not just signing. We can no longer commit stuff to the CVS repository: !ENTRY org.eclipse.team.cvs.core 4 -10 2011-05-31 09:55:14.172 !MESSAGE The server reported an error while performing the "cvs commit" command. !SUBENTRY 1 org.eclipse.team.cvs.core 4 -14 2011-05-31 09:55:14.172 !MESSAGE org.eclipse.jdt.doc.user: cvs [commit aborted]: could not open lock file `/cvsroot/eclipse/org.eclipse.jdt.doc.user/whatsNew/,jdt_whatsnew.html,': Permission denied
(In reply to comment #1) > It's not just signing. We can no longer commit stuff to the CVS repository: > > !ENTRY org.eclipse.team.cvs.core 4 -10 2011-05-31 09:55:14.172 > !MESSAGE The server reported an error while performing the "cvs commit" > command. > !SUBENTRY 1 org.eclipse.team.cvs.core 4 -14 2011-05-31 09:55:14.172 > !MESSAGE org.eclipse.jdt.doc.user: cvs [commit aborted]: could not open lock > file `/cvsroot/eclipse/org.eclipse.jdt.doc.user/whatsNew/,jdt_whatsnew.html,': > Permission denied Git is not avaiable on hudson-slave1 but on fastlane. Already tried an another host?
I was trying to delete some files in my download space and get a "No Permission" because I am on a readonly file system. Maybe thats the problem, that the disk is mounted as read-only.
I can write to /opt/public/download-staging.priv/eclipse/e4 and my zip to be signed and output directory are all there ... but after 6h it was never signed. Maybe the ro problem prevented it from being queued. PW
(In reply to comment #3) > I was trying to delete some files in my download space and get a "No > Permission" because I am on a readonly file system. Maybe thats the problem, > that the disk is mounted as read-only. Which server were you using?
download.eclipse.org and archive.eclipse.org are currently mounted read-only because there are filesystem errors. I will likely have to take it entirely offline to run a fsck.
(In reply to comment #5) > (In reply to comment #3) > > I was trying to delete some files in my download space and get a "No > > Permission" because I am on a readonly file system. Maybe thats the problem, > > that the disk is mounted as read-only. > > Which server were you using? I tried build.eclipse.org and dev.eclipse.org at /home/data/users/ccampo/downloads/rt/riena/updatesites/rienatoolbox both had their filesystem read only…. (probably the same disk anyway)
Could bug 347763 be related to this?
I wonder if that has consequences for the Indigo RC3 schedule ? Riena has everything there already but I guess not everybody has, who is in Indigo….
(In reply to comment #9) > I wonder if that has consequences for the Indigo RC3 schedule ? Riena has > everything there already but I guess not everybody has, who is in Indigo…. Too early to say. But probably not, based on similar experiences in past years. I suggest we wait till this afternoon (Eastern), to see how the recovery is going, before concluding anything. But for now I'm assuming RC3 end dates will remain the same, projects will either contribute "late", or wait will RC4. But, we'll see ... I'll comment and/or propose something on cross-project list later today.
(In reply to comment #1) > It's not just signing. We can no longer commit stuff to the CVS repository: FWIW, this is an isolated case. > !MESSAGE org.eclipse.jdt.doc.user: cvs [commit aborted]: could not open lock That directory (org.eclipse.jdt.doc.user) is owned by the jdt.core group, which you are not a member of. Both scenarios don't sound right. I think the directory should be changed to eclipse.jdt. Thoughts?
> > !MESSAGE org.eclipse.jdt.doc.user: cvs [commit aborted]: could not open lock > > That directory (org.eclipse.jdt.doc.user) is owned by the jdt.core group, More than one group should have access to that directory. For details see bug 324772 where you implemented this. > you are not a member of. Both scenarios don't sound right. Yes, I'm not a member of eclipse.jdt.core but I am a member of eclipse.jdt.ui which also needs access to that directory. > I think the directory should be changed to eclipse.jdt. Nope.
> > That directory (org.eclipse.jdt.doc.user) is owned by the jdt.core group, > > More than one group should have access to that directory. For details see bug > 324772 where you implemented this. We may have lost the extended ACLs that were created in that bug. Matt, when you set this up, were they added to our ACL script? I don't see them there.
I would've sworn they had been added. I've added and applied them. -M.
(In reply to comment #14) > I would've sworn they had been added. I've added and applied them. > > -M. Thanks! I could commit my work.
hmm.. I still get an error while trying to commit to o.e.jdt.doc.user " The server reported an error while performing the "cvs commit" command. org.eclipse.jdt.doc.user: cvs [commit aborted]: could not open lock file `/cvsroot/eclipse/org.eclipse.jdt.doc.user/whatsNew/images/,filter-getters-and-setters.png,': Permission denied "
Signing from Hudson is also still failing for Mylyn builds: https://hudson.eclipse.org/hudson/job/mylyn-release/113/console [exec] + /usr/bin/sign /home/data/httpd/download-staging.priv/tools/mylyn/hudson/signing/mylyn/site.zip nomail /home/data/httpd/download-staging.priv/tools/mylyn/hudson/signing/mylyn/output [exec] /usr/bin/sign: line 90: /opt/public/download-staging.priv/arch/signing_queue: Permission denied [exec] /usr/bin/sign: line 91: /opt/public/download-staging.priv/arch/signing_queue: Permission denied Just wondering if this expected to be working already?
(In reply to comment #16) > hmm.. I still get an error while trying to commit to o.e.jdt.doc.user > > " Looking at the permissions on the server it looks OK now but maybe it depends to which node you're connected?
*** Bug 347749 has been marked as a duplicate of this bug. ***
Argh! Was happy too early. Now got this: Problems tagging the resources. 4 project(s) successfully tagged and 1 project(s) with errors. The server reported an error while performing the "cvs tag" command. org.eclipse.jdt.doc.isv: cvs [tag aborted]: could not open lock file `/cvsroot/eclipse/org.eclipse.jdt.doc.isv/,.cvsignore,': Permission denied
(In reply to comment #20) > Argh! Was happy too early. Now got this: The mask hadn't updated earlier(it seems to happen sometimes). I've started an update of the mask on all files under /eclipse(so it'll take a while) (In reply to comment #16) > hmm.. I still get an error while trying to commit to o.e.jdt.doc.user > Have you restarted your cvs connection? If not cached permissions(or a lack thereof) are probably at fault. (In reply to comment #17) > Signing from Hudson is also still failing for Mylyn builds: > Looks like the same mask issue. Should be ok now, if it isn't let me know and I'll restart hudson. -M.
The STEM project is having trouble committing to SVN. Error: svn: Commit failed (details follow): svn: Can't create directory '/svnroot/technology/org.eclipse.stem/db/transactions/1913-1.txn': Permission denied
I am not able to commit on GMF-Tooling CVS because of permission denied. I created a new connection and retried, in vain. My groups: "common callisto-dev soa.jwt modeling.gmp.gmf-tooling" File giving me the error: "-r--rwxr--+ 1 ahunter modeling.gmp.gmf-tooling 2191 2011-05-10 23:59 pom.xml,v" in /cvsroot/modeling/org.eclipse.gmp/org.eclipse.gmf.tooling/plugins/org.eclipse.gmf.codegen.ui Seems like permissions are fine on filesystem. Maybe there are some more things to do on CVS server or client?
(In reply to comment #21) > (In reply to comment #20) > > Argh! Was happy too early. Now got this: > > The mask hadn't updated earlier(it seems to happen sometimes). I've started an > update of the mask on all files under /eclipse(so it'll take a while) > > (In reply to comment #16) > > hmm.. I still get an error while trying to commit to o.e.jdt.doc.user > > > > Have you restarted your cvs connection? If not cached permissions(or a lack > thereof) are probably at fault. Yes, I've logged off my account and restarted Eclipse. Still the same problem: I cannot commit my work for org.eclipse.jdt.doc.isv!
> Yes, I've logged off my account and restarted Eclipse. Still the same problem: > I cannot commit my work for org.eclipse.jdt.doc.isv! Apologies, we messed up the ACL. Trying to do too many things at once. I've checked, then re-checked. Then I took a shower, and re-checked again. Your next commit will succeed, or else I will email you some beer to help cope with the pain.
It worked now! Thanks!
Seems like there is still an issue with modeling/org.eclipse.gmp/org.eclipse.gmf.tooling/. Neither Michael Golubev (mgolubev) and I (mistria) is able to commit.
Mickael I'm fixing that as we speak.
Sorry for my impatience and thanks for your help, Denis.
Ok Mickael you should be all set. You were not impatient, you were inquisitive :) Matthew you're next...
(In reply to comment #22) > The STEM project is having trouble committing to SVN. > '/svnroot/technology/org.eclipse.stem/db/transactions/1913-1.txn': Permission > denied You should be all set now.
My turn :) It worked a few hours ago, but now I'm getting an error: svn: Can't create directory '/home/data/svn/modeling/org.eclipse.mdt.modisco/db/transactions/4448-1.txn': Permission denied
And also on EMF Facet: svn: Can't check path '/svnroot/modeling/org.eclipse.emft.facet/db/revs/0/709': Permission denied
Hi Matt thanks for your help. Still getting a permission denied error on commit: svn: Commit failed (details follow): svn: Can't open file '/svnroot/technology/org.eclipse.stem/db/write-lock': Permission denied
(In reply to comment #32) > svn: Can't create directory (In reply to comment #33) > svn: Can't check path '/svnroot/modeling/org.eclipse.emft.facet/db/revs/0/709': Nicolas are you still getting these errors? (In reply to comment #34) > svn: Can't open file '/svnroot/technology/org.eclipse.stem/db/write-lock': Matthew are you still seeing this error? In both cases the ACLs look ok. -M.
Yep, we're still seeing the same error svn: Can't open file '/svnroot/technology/org.eclipse.stem/db/write-lock': Permission denied Thanks, -Matt
(In reply to comment #36) > Yep, we're still seeing the same error Darned missing g+w in the ACL. Please restart your connection and let me know if this persists. -M.
Fixed! Thanks Matt
It looks like the signing process failed in our build because I don't have rights to copy the zip to our staging directory to enter the signing queue. kmoir@build:/home/data/httpd/download-staging.priv/eclipse> pwd /home/data/httpd/download-staging.priv/eclipse kmoir@build:/home/data/httpd/download-staging.priv/eclipse> mv ~/eclipse-master-I20110602-1051.zip . mv: cannot create regular file `./eclipse-master-I20110602-1051.zip': Permission denied Could you please fix this so we can continue with our build :-)
(In reply to comment #39) > Could you please fix this so we can continue with our build :-) The build iscsi device was mounted without ACL support. I've re-mounted it and I'm re-running the ACL script just to be safe. You should be OK now, or in a few minutes anyway.
Thanks Denis! It seems be be working now.
This should have been marked as fixed some time ago.
