newRepo Permission denied: '/mnt/koji/repos'
by Moray Henderson
Is this the right place for questions on local koji installations?
Fresh setup of koji on CentOS 6.2. I've got hub, web and builder all
talking to each other, external repositories defined for the build tag and
build groups set up.
/mnt/koji is an nfs mount with root squashed to uid 48 (apache). I've
tested that I can write to the subdirectories as root and the owner comes
out as apache. The directory looks like
# ll -R koji
koji:
total 16
drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 packages
drwxr-xr-x 3 apache apache 4096 Apr 12 15:20 repos
drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 scratch
drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 work
koji/packages:
total 0
koji/repos:
total 0
koji/scratch:
total 0
koji/work:
total 0
The Koji/ExternalRepoServerBootstrap document says "Wait for the repo to
regenerate, and you should now be able to run a build successfully."
However, Koji-web lists the newRepo task as failed with result "<type
'exceptions.OSError'>: [Errno 13] Permission denied: '/mnt/koji/repos'". On
the builder, kojid.log reports:
2012-04-12 14:20:31,067 [INFO] koji.build: Starting up
2012-04-12 14:20:34,363 [INFO] koji.TaskManager: Attempting to take task
176
2012-04-12 14:20:36,275 [INFO] koji.TaskManager: pids: {176: 17925}
2012-04-12 14:20:36,855 [WARNING] koji.TaskManager: FAULT:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/koji/daemon.py", line 1114, in
runTask
response = (handler.run(),)
File "/usr/lib/python2.6/site-packages/koji/tasks.py", line 146, in run
return self.handler(*self.params,**self.opts)
File "/usr/sbin/kojid", line 2491, in handler
repo_id, event_id = self.session.host.repoInit(tinfo['id'], **kwargs)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1510, in
__call__
return self.__func(self.__name,args,opts)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1760, in
_callMethod
raise err
Fault: <Fault 1: "<type 'exceptions.OSError'>: [Errno 13] Permission
denied: '/mnt/koji/repos'">
2012-04-12 14:20:37,110 [INFO] koji.TaskManager: open task: {'waiting':
None, 'id': 176, 'weight': 0.10000000000000001}
I've looked into the code, but my python is not up to debugging that. It's
not an SELinux problem (I tried permissive mode) and /mnt/koji is mounted
read-write on the builder even though the documentation says that's not
necessary. Can someone point me in the right direction?
Moray.
"To err is human; to purr, feline."
12 years
logfile rotation for kojid builder
by Florian La Roche
Hello,
the default "kojid" builder is using /var/log/kojid.log
for file logging via:
handler = logging.handlers.RotatingFileHandler(fn, maxBytes=1024*1024*10, backupCount=5)
This does not seem to work if kojid forks and rotation happens within
the forked processes and then the main process is still using the old
kojid.log file...
So rotation should probably move into the main kojid process.
Keeping to the old logfile can be easily seen in /proc/<pid kojid>/fd/.
best regards,
Florian La Roche
12 years
sessions table cleanup ?
by Thomas Guthmann
Hey guys,
We are running our own private koji instance. We are running 1.6 on el5.
Lately this query takes 20mins or so to execute :
SELECT host.id,name,arches,task_load,capacity FROM host
JOIN sessions USING (user_id)
WHERE enabled = TRUE AND ready = TRUE
AND expired = FALSE
AND master IS NULL
AND update_time > NOW() - '5 minutes'::interval
It looks like the 'sessions' table is the culprit. Indeed SELECTing
'host' is immediate whereas SELECT count(id) from 'sessions' takes 15
seconds for only 408312 rows... looks like a vacuum problem you would
say. You are right but my question is why do I have so many sessions
rows ? Can 'sessions' be truncated ? I am just wondering if it's a known
issue to not clean the sessions tables or if I need to tune my
autovacuum to work properly :)
Cheers,
Thomas
12 years
