python - Mercurial:hgwebdir 的权限被拒绝

Question

昨天，我设置了 Apache 来为我的 Mercurial 存储库提供服务，并且一切正常。然后我测试了将更改推送回此存储库并出现错误，现在我尝试的每一个操作都会弹出该错误 - 甚至只是存储库的简单 GET 请求!这是错误:

mod_wsgi (pid=1771): Target WSGI script '/var/hg/hgweb.wsgi' cannot be loaded as Python module.
mod_wsgi (pid=1771): Exception occurred processing WSGI script '/var/hg/hgweb.wsgi'.
Traceback (most recent call last):
  File "/var/hg/hgweb.wsgi", line 18, in ?
    application = hgwebdir(config)
  File "/usr/lib64/python2.4/site-packages/mercurial/hgweb/__init__.py", line 15, in hgwebdir
    return hgwebdir_mod.hgwebdir(*args, **kwargs)
  File "/usr/lib64/python2.4/site-packages/mercurial/hgweb/hgwebdir_mod.py", line 52, in __init__
    self.refresh()
  File "/usr/lib64/python2.4/site-packages/mercurial/hgweb/hgwebdir_mod.py", line 82, in refresh
    self.repos = findrepos(paths)
  File "/usr/lib64/python2.4/site-packages/mercurial/hgweb/hgwebdir_mod.py", line 36, in findrepos
    for path in util.walkrepos(roothead, followsym=True, recurse=recurse):
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line 1164, in walkrepos
    for hgname in walkrepos(fname, True, seen_dirs):
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line 1146, in walkrepos
    for root, dirs, files in os.walk(path, topdown=True, onerror=errhandler):
  File "/usr/lib64/python2.4/os.py", line 276, in walk
    onerror(err)
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line 1127, in errhandler
    raise err
OSError: [Errno 13] Permission denied: './dev/fd'

我的存储库目录归 apache 所有，运行 Apache 的用户。我不知道为什么要对“./dev/fd”进行操作。我已经多次重启服务器，重新创建存储库目录，但无论如何我仍然会收到此错误!我无权重新启动机器，所以这不是一个选项。但它似乎已经进入了一个非常糟糕的持久状态，我不知道如何解决它。感谢您的帮助!

Answer 1

结果证明这是我的配置错误，我不会删除问题，而是会在此处发布解决方案，以防将来有人遇到此问题。

这是我使用的 hgweb.config:

[paths]
/ = /var/hg/repos/*

#[web]
style = gitweb
allow_archive = bz2 gz zip
maxchanges = 200
allow_push = *
push_ssl = false

这里有两个问题，一个是显而易见的。我将 [web] header 注释掉了，并且我假设许多选项对 [paths] 部分无效。此外，再次阅读 Hg 文档后，push_ssl 指令不属于 hgweb.config 文件，而是属于每个存储库的 .hg/hgrc(或运行 apache 的用户的 ~/.hgrc)。修复这些问题后，一切正常!