emerge: "IOError: [Errno 13] Permission denied"

hielvc · Posted: Thu Nov 09, 2006 3:42 pm Post subject:

What are your permissions on /mnt/data/portage/distfiles/ ? What does df -h show ? What does "date" return on both boxins ? If the affore mentioned look good can you "touch /mnt/data/portage/distfiles/test.file" and "touch /var/tmp/portage/test.file"
_________________
An A-Z Index of the Linux BASH command line

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

Owner t0maz:portage (portage group for portage and t0maz because I cifs-mount it as t0maz) with permissions 0755. df -h says 6GB available, date is about the same on both (a few seconds difference). I can touch both files. I don't think that's the kind of problems to look at because as I said: it worked, I probably screwed something up by pressing some wrong keys and then it stopped working.

Genone · Posted: Fri Nov 10, 2006 3:18 pm Post subject:

Check permissions of $DISTDIR/.locks and files in it. If that doesn't help you might need to set FEATURES="-distlocks" in make.conf (or if you have userfetch enabled disable it).

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

With that option it works. What do you suggest to fix this permanently?

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

hielvc · Posted: Tue Nov 14, 2006 4:18 pm Post subject:

I suspect that it was a stale lock file. "lock" files are mechcanisms that help progarms keep track of what the left and right hands are doing. Most people are running mutipule makes, -j3. So when make1 starts compiling line1 it sets a lock file that makeMaster can use to keep the next make2 from building the same line1 and instead tells to it to build line2. When make1 is done its suppose to remove its lock file, get a new line an make another lock file. Some times the earth moves and that first lock file doesnt get removed. Portage also uses lock files and for some reason it didnt get removed. If you can figure out how to prevent randome glitchs like this on computers Billy Bob Gates would like to talk to you. :wink:

_________________
An A-Z Index of the Linux BASH command line

Genone · Posted: Tue Nov 14, 2006 10:41 pm Post subject:

Sorry, don't know the internals of the locking subsystem, probably best to file a bug so Zac can take a look.

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

hielvc, I understand how it works but I didn't mean 'permanently' as to get rid of general problems with lockfiles but still this specific case. Now I have -distlocks still in my FEATURES and I'd like to know a way so I can remove that and use portage 'normally' again. I have already tried removing lockfiles in the $DISTFILES/.locks directory but are there any other lockfiles I could try to remove to fix this?

Genone: I would fix a bugreport... IF I would know how to reproduce this...

Mickael · Posted: Wed Nov 15, 2006 2:35 pm Post subject:

Hi,

if you use reiser filesystem, try this :

take a live CD and :

Genone · Posted: Wed Nov 15, 2006 2:42 pm Post subject:

Mickael · Posted: Wed Nov 15, 2006 3:15 pm Post subject:

thomasvk · Guru Joined: 19 Mar 2005 Posts: 599

Well now I get this on my laptop too... while yesterday it still worked perfectly and I didn't change anything since then. Not even a portage upgrade or anything.

Any ideas on how to fix this?

TinheadNed · Posted: Fri Dec 22, 2006 2:41 pm Post subject:

I've started getting this, but with a different backtrace

casso

I am still finding that this issue is occurring on portage-2.1.4.4. I have looked through some of the code to see exactly what is going on. I can't say that I have it perfectly down, but I believe this is what happens. I assume that userfetch is listed in your FEATURES variable. The code in question is in the file /usr/lib/portage/pym/portage_locks.py

1. If a lock file does not exist, then create the file with mode 0660 as portage:portage. With the file handle now created for the file, attempt to lock the file:
fcntl.lockf(myfd,fcntl.LOCK_EX|fcntl.LOCK_NB) or similar
2. If a lock file does exist, then simply gain a file handle to it and attempt to lock the current file in the same manner. There are a few exceptions that are checked in case the lock does not succeed. One of these is NOT our IOError 13: Permission Denied error from what I can gather.

I have checked my Samba server to see if it is causing permission problems. At the start of this exercise it was, but I have since resolved that and found that the same conditions still exist. I know the original error in this post was pointed at trouble unlocking the file, which could be an inode issue (use serverino mount option), but the issue has spread to when two instances of portage attempt to work with lock files. Of interest is the fact that the Samba server has no problems with the lock files when a CIFS client has locked a file before the server gets to it.

I do believe that this is a genuine bug, but wanted some feedback before I decide to submit a bug report.
_________________
Need assistance with any of the following? Just PM me and I will see what I can do

LDAP, Kerberos , SSH, Samba, PPP, DHCP, NTP, autofs, CUPS