Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 637088 - sys-apps/portage: "Cannot chown a lockfile" message triggered for users that are not members of the "portage" group
Summary: sys-apps/portage: "Cannot chown a lockfile" message triggered for users that ...
Status: IN_PROGRESS
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-10 20:18 UTC by William L. Thomson Jr.
Modified: 2017-11-15 21:11 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William L. Thomson Jr. 2017-11-10 20:18:05 UTC
Got some funky output when using --tree/-t combined with --usepkg/-k


$ emerge -pkv1 --tree tiles-extras
[Errno 1] Operation not permitted: b'/usr/portage/packages/amd64/.Packages.portage_lockfile': chown('/usr/portage/packages/amd64/.Packages.portage_lockfile', -1, 250)
Cannot chown a lockfile: '/usr/portage/packages/amd64/.Packages.portage_lockfile'
Group IDs of current user: 6 7 10 18 19 20 27 36 80 100 106 250 265 409 412 450 500 1015 1026 1027 10001 10002 10003 10004 10005 10006 10007 10008 10009 10010 10011 10012 10013 10014 10015

These are the packages that would be merged, in reverse order:


Without --usepkg/-k


$ emerge -pv1 --tree tiles-extras

These are the packages that would be merged, in reverse order:


Moot to me, just reporting for others. Address however, maybe preventing the two or something.
Comment 1 Zac Medico gentoo-dev 2017-11-10 20:39:17 UTC
The correlation that you observed does not necessarily indicate causation. It looks like you experienced a temporary issue with /usr/portage/packages/amd64/.Packages.portage_lockfile that was certainly related to the --usepkg/-k option but probably unrelated to the --tree/-t option.
Comment 2 William L. Thomson Jr. 2017-11-10 21:32:43 UTC
Yes, it turns out this was a permissions issue. Lockfile was created via root and portage run as user. When it did not exist, the error did not occur.

Just how portage handles that error. I would assume something like, error lock file created by root, etc. Though not sure it needs to lock with pretend? Either way least the trigger/cause is known. Should be easy to replicate.
Comment 3 Zac Medico gentoo-dev 2017-11-10 22:22:26 UTC
The reason for the lock is that it has the ability to automatically update $PKGIR/Packages in order to cache metadata for future runs. This behavior is helpful if $PKGIR/Packages is missing for some reason, or if someone has added some additional packages without updating the $PKGIR/Packages file.

The lock is only acquired if the current user has write access:

			if os.access(self.pkgdir, os.W_OK):
				pkgindex_lock = lockfile(self._pkgindex_file,
					wantnewlockfile=1)

The lockfile function assumes that it should grant write access to the portage group, but that fails if the current user is not in the portage group.
Comment 4 Zac Medico gentoo-dev 2017-11-11 21:07:10 UTC
There's no point in trying to add group write access to the file unless that group also has write access to the parent directory. So, it would make sense for the lockfile function to stat the parent directory and apply group write permission if the parent directory also has it.
Comment 5 William L. Thomson Jr. 2017-11-12 16:36:28 UTC
(In reply to Zac Medico from comment #3)
>
> The lockfile function assumes that it should grant write access to the
> portage group, but that fails if the current user is not in the portage
> group.

My user is in the portage group.

$ grep portage /etc/group
portage:x:250:portage,wlt

My whole tree is wlt:users

$ ls -l /usr/
...
drwxr-xr-x 175 wlt  portage   4096 Oct  5 00:11 portage


When I run as root, pretty sure lock file is root:root, vs root:portage. Maybe need to set group sticky bit or something.
Comment 6 William L. Thomson Jr. 2017-11-13 19:27:16 UTC
It looks like portage is trying to chown a file that does not exist. Unless the lock file is created and goes away in seconds. I am getting the error back to back now on every run. I also try to ls the file at the same time and it is not there.

In this case no other systems are running emerge. I am on my desktop, I did a pretend, no error. Then I did it again and I get the cannot chown lockfile error. Which I get on subsequent runs now as the same user. I keep doing ls and can't see file at all. Thus I am not sure its ever created in the first place. Which could explain the error trying to chown a file that does not exist.
Comment 7 Zac Medico gentoo-dev 2017-11-13 19:59:56 UTC
The file definitely exists when portage calls chown, it's just removed quickly. If the file didn't exist then chown would raise ENOENT or ESTALE, and the message is not displayed in that case:

	try:
		if os.stat(lockfilename).st_gid != portage_gid:
			os.chown(lockfilename, -1, portage_gid)
	except OSError as e:
		if e.errno in (errno.ENOENT, errno.ESTALE):
			return lockfile(mypath,
				wantnewlockfile=wantnewlockfile,
				unlinkfile=unlinkfile, waiting_msg=waiting_msg,
				flags=flags)
		else:
			writemsg("%s: chown('%s', -1, %d)\n" % \
				(e, lockfilename, portage_gid), noiselevel=-1)
Comment 8 William L. Thomson Jr. 2017-11-15 21:11:51 UTC
Ok I run into that as well like in bug 636798 Having all sorts of binary fun :)