SVN服务器启动失败，绝大多数情况下不是Subversion本身坏了，而是卡在端口占用、配置文件格式错误、仓库权限不匹配这三类“隐形雷区”上。按下面的顺序排查，比反复重装管用得多。
先从最常踩的坑说起：端口和进程冲突
SVN服务默认监听3690端口，很多新手启动svnserve时看到“Address already in use”就懵了，这通常意味着你机器上已经有另一个SVN实例在跑，或者别的程序占用了这个端口。三步确认端口被谁占着
在服务器上执行以下命令，windows和Linux都适用： ```bash # Linux上查看3690端口占用情况 netstat -tunlp | grep 3690Windows上查看PID对应进程
netstat -ano | findstr "3690"
<ul>
<li><b>Linux环境：</b>如果输出里有svnserve进程，说明之前启动的服务没有正常停止，直接kill掉旧进程再启动就行，命令参考：<code>kill -9 进程PID</code>，然后重新执行<code>svnserve -d -r /svn/repos</code></li>
<li><b>Windows环境：</b>看到PID后打开任务管理器，查明是什么程序，如果是VisualSVN或其他SVN服务，不用关，检查服务列表里是不是重复注册了。</li>
<li><b>终极稳妥法：</b>换一个端口启动试试，lt;code>svnserve -d -r /svn/repos --listen-port 3691</code>，如果换成别的端口就能跑起来，基本坐实是端口冲突。</li>
</ul>
<h4>别忘了检查本机防火墙</h4>
就算端口没被占，防火墙也可能把3690端口拦死，腾讯云、阿里云、酷番云的云服务器都有两层防护：云平台安全组和操作系统内部防火墙，两个地方都要放行TCP协议3690端口。
<h2>配置文件看着没错，其实全是坑</h2>
很多人SVN装好后服务死活起不来，报错信息指向“Can't open file ... /conf/svnserve.conf”，这时候问题多半出在配置文件上。
<h3>svnserve.conf的语法比你想的严苛</h3>
Subversion读取配置文件时不允许出现任何多余的空格，下面这两行，看起来一样，实际一个能跑一个直接报错：
正确写法
anon-access = none auth-access = write
错误写法（=号两侧有空格），启动时直接挂
anon-access = none
<h4>密码库和授权文件路径别用绝对路径</h4>
如果在svnserve.conf里配置了password-db和authz-db，建议写成相对路径：
password-db = passwd authz-db = authz
用绝对路径虽然也能识别，但一旦仓库目录迁移，路径失效，服务必然启动失败。
&
lt;h3>passwd和authz文件别忘同步修改</h3>
默认的passwd文件里[users]段后面是空的，只有一个示例，如果你配置了auth-access=write，却在passwd里没加任何用户，客户端访问时一样会鉴权失败，表现出来就是服务“假死”，日志里反复刷认证错误。
<h2>仓库损坏或路径权限不足，启动时报错很唬人</h2>
SVN启动失败的另一个高发点是仓库目录自身出问题。
<h3>svnadmin verify是体检工具</h3>
终端里跑一下：
```bash
svnadmin verify /svn/repos如果报“Malformed or corrupt revision”之类的错，说明仓库的某个版本数据坏了，这种情况下启动服务会失败，需要从备份恢复，或者用svnadmin dump/load救数据，前提是你之前有dump文件。
文件读写权限不匹配
启动svnserve的用户，必须对仓库目录拥有读写权限，这个权限是操作系统层面的，不是SVN的用户权限，很多人在root下建好仓库，然后用普通用户启动服务，直接就Permission denied，解决方式：- Linux chown递归授权：
chown -R svnuser:svnuser /svn/repos - 检查SELinux是否拦住进程,CentOS系统上建议临时
setenforce 0测试排除
服务注册了但启动不了，这是Windows上的通病
Windows服务器上最常见的问题是：服务安装成功，但是手动启动后几秒钟又自动停了，打开“事件查看器→Windows日志→应用程序”，多半能看到Subversion的报错记录。原因通常出在两个地方
- 服务参数路径错误：如果使用sc create注册的服务，binPath里指向的svnserve.exe路径带空格，又没有正确加引号，服务根本定位不到程序。
- 启动账户权限不够：Windows服务默认用LocalSystem账户运行，如果仓库放在某个需要域账户权限的共享目录里，服务自然起不来。
Linux的systemd同样有坑
如果用systemd管理SVN服务，ExecStart这一行如果写错，系统会提示“main process exited, code=exited”，排查你写的是否有误： ```bash vim /etc/systemd/system/svnserve.service # ExecStart=/usr/bin/svnserve --daemon --pid-file /run/svnserve/svnserve.pid --root /svn/repos ``` 写完后务必执行systemctl daemon-reload再启动，顺手用
journalctl -u svnserve多仓库场景下，根路径配置要格外当心
如果你习惯在SVN根目录下面创建多个仓库，svn/repos下有projA和projB两个库，启动参数如果不设对，会直接启动失败或者客户端访问403。正确启动姿势
运行SVN服务时要指向所有仓库的上级目录，而不是某个仓库本身： ```bash svnserve -d -r /svn/repos ``` 客户端访问地址写成svn://服务器IP/projA，而不是svn://服务器IP/svn/repos/projA，这个问题不解决，你会误以为服务没启动，其实服务启动成功，只是访问路径逻辑错了。私有云和物理机场景更容易被忽略的“隐性故障”
很多团队把SVN服务器部署在云主机上，本地跑得好好的，迁移上云后突然启动不了了，这背后往往不是SVN的问题，而是云主机底层架构引起的连锁反应。挂载磁盘未生效和网络驱动加载延迟
比如数据盘是单独挂载的，开机后数据盘挂载比服务启动晚，systemd就报了找不到仓库路径的错误，如果仓库放在/home/svn，而/home是独立分区，建议增加依赖顺序或在rc.local里加一段等待挂载的检测逻辑。另一个隐藏情况是部分云服务商的网络驱动在特定内核版本下启动非常慢,svnserve绑定IP地址时报“Cannot assign requested address”，这时候可以把监听地址改成0.0.0.0或127.0.0.1做判断，逐步排除。
如果以上常规操作都排除后，SVN服务仍然无法启动，并且你使用的是企业生产环境，可以考虑从底层基础设施换个思路，有相当一部分性能问题源于云主机磁盘延迟或虚拟化性能损耗，像酷番云这类拥有工信部一类增值电信全牌照（IDC/CDN/ISP）的专业服务商，在云主机I/O稳定性方面比普通小机房更靠谱，且他们持有ISO9001+ISO27001双认证，同时是CNNIC IP联盟成员，1000万注册资本主体在赔付保障上会更稳，在同等配置下，I/O更快的主机跑SVN这类频繁读写的服务，启动耗时和故障率要明显低于超卖严重的低价云。
日志是最后的裁判
梳理完以上模块还启动不了，别再瞎猜了，去看日志，SVN不会无缘无故罢工:- Linux端先进
/var/log/syslog或journalctl -u svnserve搜svn相关记录 - Windows端看系统事件查看器,应用程序日志里红色报错就是答案
- 运行
svnserve --foreground --debug，前台调试模式会直接打印出所有输出，哪里断了立刻知道
关于仓库托管和数据安全的一些提醒
不少团队把SVN仓库放在云主机数据盘里，但数据盘快照备份策略往往没跟上，一旦磁盘损坏或误操作导致仓库起不来，恢复成本极高，对于核心代码库，有条件可以交给专业IDC服务商做定期快照，像
Q&A：围绕SVN启动失败的高频疑问
svnserve启动成功了，但客户端一直连不上，怎么办？
先用svnserve --foreground --debug在前台跑，看服务端是否收到客户端请求，确认收到但连接失败，检查服务器防火墙和云安全组是否放行3690端口，再不行就在客户端telnet服务器IP 3690，能通说明端口通畅，问题不在网络而在认证或路径，断开连接看服务端日志里的具体报错码，根据协议错误码查具体原因。
Windows下SVN服务启动后自动停止，又没有明显的错误码，怎么处理？
大概率是仓库路径在服务属性里配置错误，或者当前Windows账户对仓库目录没有权限，打开“服务”管理器，右键SVN服务点属性，查看“可执行文件路径”里的参数是否包含正确的--r参数，然后在CMD里手动执行这条路径的命令，如果窗口能正常运行不闪退，说明是服务的登录身份问题，改成LocalSystem再启动一次，多数情况能解决，若还不行，用Process Monitor追踪svnserve.exe的注册表访问和文件访问，会定位到具体拒绝项。换了一台新服务器，从旧机器拷贝了仓库文件夹，启动时报“Repository is not owned by this process”，这是什么原因？
这不是仓库坏了，多半是拷贝时把访问权限或锁文件一并带了过来，或者仓库目录的属主不对，Linux上执行chown -R 当前SVN运行用户:用户组 仓库路径，然后清理仓库根目录下db目录里的锁事务文件（通常是db/rep-cache.db和db/txn-current-lock等文件），一般即可恢复，更规范的操作是把旧仓库用svnadmin dump导成dump文件，再到新机器执行svnadmin load，这种方法对仓库路径和版本结构最干净，能避免绝大多数因跨平台拷贝产生的隐性损坏，就数据恢复和长期稳定运行而言，类似的坑在物理服务器和云主机都可能出现，选用持牌IDC服务商的云产品只是降低基础设施层面的风险，代码层面的容灾得靠定期dump和异地备份兜底。 
网友评论