記錄下來方便今後查閱
今早有同事反應svn無法提交。總是在提交的進度條完成後卡死在那裏，無法點擊確定。但是其它svn客戶端svn up後可以接收到他提交的文件。也就是說提交實際上是完成了的，但是出於某種原因提交的進程一直未能順利結束。
後來登錄服務器查看svn進程狀態
# ps aux | grep svn
root 8925 0.0 0.0 142528 1108 ? Ss 10:09 0:00 svnserve -d -r /data/svn_files/
sshpass -p zzzzz ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system_rl/template&&svn update"
......
會看到很多類似的進程。
停掉所有的svn服務及相關服務。然後再重新啓動svn。再次提交問題依然存在，查看svn進程狀態，還是和上述狀態差不多。我們沒有手動啓動sshpass -p ...這一行命令。而這行命令卻隨着我們svn的提交而自動生成了。這關係到一個文件post-commit。這是一個勾子文件，能夠伴隨着svn commit（提交）而自動觸發裏面的腳本。所以，當svn提交時，裏面的sshpass這個命令也就跟着觸發執行了。而且，當觸發的腳本完成之前，提交任務就不會標記結束！所以，可以判定很可能是這條觸發語句未執行成功而導致提交一直卡死。
# vim hooks/post-commit
sshpass -p 123456 ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system&&svn update"
.....
那麼我們可以把裏面的命令拿出來執行看看。
# sshpass -p 123456 ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system&&svn update"
進程一直卡死在這裏了。問題就在這裏。
註釋掉post-commit的所有行。客戶端再提交，這次提交順利完成了！
# vim hooks/post-commit
#sshpass -p 123456 ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system&&svn update"
.....
Svn 問題就此解決。
MFS問題：
先在svn服務器10.6.0.100上分析
但是那條語句如果不能自動執行，那麼10.6.0.6就不能自動svn up了。所以再解決
sshpass -p 123456 ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system&&svn update"
執行失敗的問題。
先去掉&&svn update執行這條語句。
#sshpass -p 123456 ssh [email protected] "cd /opt/data/mfs/folder2/htdocs/moxian_system
這條語句執行成功。加上後面的svn up後就卡死。那麼證明問題出在了客戶端的svn up上面。
回到客戶端10.6.0.6上分析
在客戶端切換到對應svn更新目錄下
# cd /opt/data/mfs/folder2/htdocs/moxian_system
#svn up
卡死了！
回到其它的目錄下，比如root目錄下。
# svn co svn://10.6.0.2/yx/share/moxian_system
檢出正常。執行svn up命令也正常。而只在moxian_system目錄下不正常。
用mount命令可看到 /opt/data/mfs/folder2/htdocs/moxian_system這個是掛載的。
# mount
......
mfs#mfsmaster:9421 on /opt/data/mfs type fuse (rw,nosuid,nodev,allow_other,default_permissions)
所以是掛載磁盤的問題。後來償試在掛載磁盤中添加文件。也總是無響應。查看一下系統日誌
# tail -1000 /var/log/messages |grep error
Oct 16 14:20:48 localhost mfsmount[3089]: error writing file number 147: ENOSPC (No space left on device)
顯示沒有空間了！查看一下掛載磁盤的空間
[root@localhost ~]# df -h
mfs#mfsmaster:9421 405G 12G 393G 3% /opt/data/mfs
空間也是有的。不是磁盤空間問題。
訪問：http://10.6.0.6:9425/mfs.cgi 出現如下報錯。
Traceback (most recent call last):
File "./mfscgiserv", line 293, in run_cgi
execfile(self.file_name)
File "/opt/local/mfs/share/mfscgi/mfs.cgi", line 117, in ?
exit()
TypeError: 'str' object is not callable
配置文件錯誤。原來的master設成了10.6.0.6.而實際應該是10.6.0.100。下面改過來。
[root@localhost mfscgi]# vim /opt/local/mfs/share/mfscgi/mfs.cgi
try:
if fields.has_key("masterhost"):
masterhost = fields.getvalue("masterhost")
else:
masterhost = '10.6.0.100'
except Exception:
masterhost = '10.6.0.100'
開始地址設錯了。正常後應該進入管理界面。在disk欄目顯示中的status列,顯示10.6.0.9這臺服務器爲error。後來發現是chrunk沒有啓動起來。
#/opt/local/mfs/sbin/mfschunkserver restart
再訪問http://10.6.0.6:9425/mfs.cgi
現在正常了。再訪問/opt/data/mfs目錄一切都正常了。
最後：
10.6.0.100
root@localhost# ps aux | grep mfs |grep -v grep
mfs 79725 0.0 0.9 154908 143024 ?? S< 2:09PM 0:14.23 /opt/local/server/mfs/sbin/mfsmaster restart
10.6.0.6
[root@localhost moyu]# ps aux | grep mfs |grep -v grep
mfs 3181 0.2 0.6 124108 25924 ? S<l 14:21 0:13 ./mfschunkserver start
root 3259 0.4 0.4 431420 17952 ? S<sl 14:23 0:20 /opt/local/mfs/bin/mfsmount /opt/data/mfs -H mfsmaster -p
root 4002 0.1 0.2 136616 11160 ? S 14:58 0:04 python ./mfscgiserv
10.6.0.9
root@localhost:/root#ps aux | grep mfs |grep -v grep
mfs 789 1.0 0.3 4388 2968 ?? R< 8Oct12 40:10.24 /opt/local/mfs/sbin/mfsmetalogger start
mfs 24856 1.0 4.0 47500 41364 ?? S< 11:05PM 0:32.67 /opt/local/mfs/sbin/mfschunkserver restart
總結：mfschrunkserver沒有啓動。