發現使用curl訪問此https的連接有問題，
網站支付需要和財付通進行一個對接，財付通給了一個https的接口連接
將此連接放入到PHP的頁面中調用curl獲取此鏈接的返回信息，
然後隨便找了一個http的連接試了試是正常的
看來是curl訪問https類型的連接有問題
應該是openssl有貓膩，
然後重新編譯安裝了一下openssl
下載地址：http://www.openssl.org/source/
openssl 編譯 ./config --prefix=/usr/local/openssl
然後把PHP重新編譯一下，加入參數：--with-openssl=/usr/local/openssl
編譯安裝之後發現問題解決了
如果問題沒有解決，建議再看看libmcrypt、mhash、mcrypt有沒有問題
值得注意的是https走的端口是443端口，所以也有必要看看防火牆的規則！
nrpe出現獲取狀態未知（UNKNOWN）
監控報警有兩個服務監控狀態是UNKNOWN
提示無法獲取/var/tmp/下的數據文件，
到監控服務器的/var/tmp下查看一下發現
文件的權限和所屬都被改動，估計是因爲手動執行腳本造成的
把此文件刪除掉，等待nagios自動生成，恢復正常狀態！
nginx中打開php是空白頁
公司內網的GM系統php網站打開顯示空白頁。
查看日誌，正常返回200，應該不是nginx的問題，可能php有問題，
打開同臺機器的其他php網站都顯示正常，看來應該是server裏面location的配置有誤；
對比了一下正常的server配置，發現有一條語句不對
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
修改完發現nginx中打開原來的php頁面顯示正常，問題解決。
查了網上資料，發現nginx配置fastcgi模式時，至少需要兩個參數，一個是fastcgi_pass，另一個是fastcgi_param SCRIPT_FILENAME。第一個負責將php腳本傳遞給php-
fpm，而第二個是幫助php-fpm找出具體的腳本路徑。如果第二個錯了，那麼可能會出現nginx中打開php是空白頁的情況。
Nginx訪問css和js的時候返回403錯誤或者返回
看到403應該是權限的問題，將目錄權限修改最大照樣不行
試着隨便創建一個文件，在裏面隨便寫了一串代碼，訪問還是403
檢查Nginx主機的配置，也沒問你
重新將配置文件寫了一邊，重啓Nginx，發現問題解決了，奇怪的是對比之前的代碼，內容完全一樣啊
估計屬於Nginx的小Bug吧
XenServer裏的虛擬機掛起狀態，無法關閉、重啓
一個虛擬機爲掛起狀態，無法連接
使用xe vm-shutdown uuid=xxxx無法關閉
使用xe vm-reboot uuid=xxxx也無法重啓
一直卡在那裏沒有反映
最後使用 list_domains 找出該uuid對應的域ID
然後 /opt/xensource/debug/destroy_domain -domid XX 來斷開外聯設備
xe vm-reboot uuid=XXXX --force 終於關閉
然後啓動一切正常
Nginx支持PHP的patn_info配置，加載css和js模塊失敗（返回403）
cp線上支持path_info的配置，做測試環境，
結果發現測試頁面http://www.xxx.com/index.php/Admin/Public/login裏面加載css和js的模塊失敗，返回403錯誤
檢查配置文件發現 location ~ .*\.(php|php5)?$
修改成 location ~ .*\.(php|php5)
問題解決！
PHP的$_SERVER['PATH_INFO']返回空值，cgi.fix_pathinfo的設置
之前站點沒有使用pathinfo，爲了環境安全，將cgi.fix_pathinfo的值改爲0進行關閉（默認是1，開啓的）
nginx默認是不會設置PATH_INFO環境變量的的值，需要php使用cgi.fix_pathinfo=1來完成路徑信息的獲取，但同時會帶來安全隱患，需要把cgi.fix_pathinfo=0設置爲0，這樣php就獲取不到PATH_INFO信息，那些依賴PATH_INFO進行URL美化的程序就失效了。
現在需要path_info的支持，將cgi.fix_pathinfo修改爲1，$_SERVER['PATH_INFO']的賦值才正常
不過cgi.fix_pathinfo=1有一定危險
比如訪問下面這個 URL：
http://php.com/a.jpg/b.php
那麼根據上面給出的配置，nginx 傳遞給 FastCGI 的 SCRIPT_FILENAME 的值爲：
/home/verdana/public_html/unsafe/a.jpg/b.php
也就是 $_SERVER['ORIG_SCRIPT_FILENAME']。
當 php.ini 中 cgi.fix_pathinfo = 1 時，PHP CGI 以 / 爲分隔符號從後向前依次檢查如下路徑：
/home/verdana/public_html/unsafe/a.jpg/b.php
/home/verdana/public_html/unsafe/a.jpg
直到找個某個存在的文件，如果a.jpg裏面是一些危險的PHP代碼，那麼就杯具了
修改php-fpm的配置，啓動錯誤：
pm.min_spare_servers(50) and pm.max_spare_servers(3000) cannot be greater than pm.max_children(1500)
由於壓力測試，將PHP調整爲動態進行測試，開啓dynamic直接重啓就報錯了
查看了dynamic生效的配置，發現問題
錯誤原因，按照這個原則去配置
min_spare_servers ≤ start_servers ≤ max_spare_servers ≤ max_children
Nginx部分頁面顯示502錯誤
測試GM系統時，點擊“遊戲”就會返回502錯誤，其他頁面都正常顯示！
測試系統無壓力，談不上進程不夠和超時時間的問題，查看了一下Nginx錯誤日誌發現
2014/04/21 16:35:41 [error] 10355#0: *1005 upstream sent too big header while reading response header from upstream, client: 10.150.1.106, server: jlgm......
意思是：nginx緩衝區有一個bug造成的,我們網站的頁面消耗佔用緩衝區可能過大
那是試着調整fastcgi的緩存區
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
重新加載後問題解決！
Nginx連接無反映，日誌返回499錯誤
所有配置和前端都沒做修改，就突然連接就沒了反映，看日誌多是499的返回
引起499錯誤的有一下原因，客戶端主動斷開，緩存區不夠用，php進程不夠用，php執行時間太長
客戶端斷開可以排除，緩存區前天才調大的，那有可能是PHP的問題了
默認PHP的進程是5個，肯定是不夠用了
調整PHP的進程數和超時時間，問題解決！
啓動Mysql報錯Another MySQL daemon already running with the same unix socket.
一臺測試服務器長時間沒用，後在虛擬機上進行遷移
啓動mysql時候報錯：Another MySQL daemon already running with the same unix socket.原因是多個mysql進程使用一個socket，可能是遷移的時候造成的
解決辦法：重啓服務器或者將socket改名即可（mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak）
cacti登陸沒反映的問題
今天登陸cacti發現登陸沒反映，一直停留在登陸頁面
刷新cacti查看日誌沒報錯，
apache的日誌發現報錯：
PHP Warning: session_start(): open(/var/lib/php/session/sess_trt4pen2apj1sab2k7290ri161, O_RDWR) failed: Permission denied (13) in /var/www/html/include/global.php on line 154
看到Permission denied就想到權限，二話不說先修改session目錄權限試試
加權之後問題解決！
cacti登陸沒反映的問題2
時隔一個月登陸cacti發現登陸又沒反映，一直停留在登陸頁面
查看日誌發現日誌不動,最後一條記錄是前一個小時的錯誤記錄,關於sql的1017錯誤
由於日誌文件已經超過2G,排查打開比較慢,所以就打包生成新的日誌文件
奇蹟出現了,打包完產生新文件,問題就解決了
登錄正常了
mysql初始化之後創建表報錯！
把以前的數據庫初始化，刪除數據來使用，刪除datadir下的所有文件，然後初始化數據庫
啓動之後在數據庫裏創建表報錯，
原因是數據庫引擎是innodb的，初始化刪除datadir下的文件還不夠，需要把innodbdata目錄下的ibdata1文件一併刪除，或者乾脆把上級目錄刪除重新創建授權
問題解決！
PHP獲取時間差8小時問題
遊戲官網（PHP）獲取用戶角色信息時間有問題，新服剛開服用戶激活發現數據庫裏面記錄的激活時間爲凌晨，但是當時遊戲還沒開服，而且正好差8小時，應該是時區問題
服務器date查看時間是正確的，時區也沒問題，拿應該是PHP的問題
php.ini配置文件裏面date.timezone 字段是註釋的，所以默認獲取的是格林威治時間
只需要date.timezone = Asia/Shanghai 問題解決！
mysqld_safe啓動mysql多實例指定配置文件報錯
/home/mysql/bin/mysqld_safe --user=mysql --defaults-file=/home/cactimysql/my.cnf &
使用上面命令啓動mysql，結果報錯：unknown variable 'defaults-file=/home/cactimysql/my.cnf'
查了一下mysql的手冊，原來指定配置文件啓動需要把--defaults-file參數放在第一位，命令如下
/home/mysql/bin/mysqld_safe --defaults-file=/home/cactimysql/my.cnf --user=mysql &
問題解決
mysql啓動報警warning: World-writable config file /home/mysql/my.cnf is ignored
原因：my.cnf的讀取權限進行了設置，不允許World-writable(字面意思是全世界都可讀寫)
解決方法：
sudo chmod 644 /home/mysql/my.cnf
rsync ERROR: setgroups failed 錯誤
這個問題通過谷歌得知是由於版本問題，具體詳細沒時間瞭解
更換到3.1.0一下版本解決（測試3.0.8和3.0.6沒有問題）
aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
aapt: error while loading shared libraries: libz.so.1: wrong ELF class: ELFCLASS64
上面是兩個報錯，剛開始執行python的一個程序是報找不到庫文件，find一下然後軟連過去，就報下面的錯，是32位系統和64爲系統庫文件不兼容導致的，python程序使用的是32爲環境編寫的，而運行在64爲的linux系統下所以報錯
解決辦法：
安裝libstdc++和libstdc++.i686
/lib/libz.so.1: no version information available
在使用aapt時，出現了/lib/libz.so.1: no version information available 警告信息，但命令還是可以執行的
之前zlib是用yum安裝的，版本爲1.2.3，網上查了一下，是版本的原因，安裝新的版本就好了
從http://zlib.net/下載最新版本wget http://zlib.net/zlib-1.2.7.tar.gz
tar zxvf zlib-1.2.7.tar.gz
cd zlib-1.2.7.tar.gz
./configure
make
make install
#覆蓋原版本，可以先備份一下原版本
cp /usr/local/lib/libz.so.1 /lib/