[FC20]Chrome開網頁會Crash的問題


OS: Fedora 20(Linux kernel 3.17.7 x86_64)
Chrome: 39.0.2171.95 (64-bit)

nVidia Driver: kmod-nvidia-304xx-3.17.7-200.fc20.x86_64-304.123-1.fc20.22.x86_64

問題: Chrome在開某些Javascript或是畫面上有很多廣告元件和圖檔時常會變成Chrome專有的哭臉貢面,必須關閉出問題的Tab後再重新開一個。當同時開多個Tab時更為明顯。

     這個問題持續好一陣子了,一直沒有去深究到底是為什麼?抱著更新之後應該就會好了,在做了兩周的更新後,似乎都沒有改善。只好動手開始找問題,開始以為是我的Profile檔案有問題,就用老方法 - 把現在的Profile備份起來後(PS. Chrome的Profile檔案在/home/michaelr/.config/google-chrome 目錄下),刪掉再重新開啟Chrome,讓Chrome自己重新產生一份新的Profile。但似乎沒有效果,仍然會有Crash的哭哭臉頁面跑出來。

     藉由在console中執行chrome來查看Chrome的顯示的錯誤訊息時,可以看到類似以下的錯誤訊息。





[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED

[WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.

[WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.

...

[12695:12733:1227/081954:ERROR:net_util_posix.cc(168)] getifaddrs: 開啟太多檔案

[WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.

...


[12695:12726:1227/081954:ERROR:host_shared_bitmap_manager.cc(144)] Cannot create shared memory buffer

[12695:12729:1227/082335:ERROR:channel.cc(290)] RawChannel read error (connection broken)

[12695:12729:1227/082428:ERROR:channel.cc(290)] RawChannel read error (connection broken)

[12695:12726:1227/083559:ERROR:host_shared_bitmap_manager.cc(144)] Cannot create shared memory buffer

[WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.

...


只好請出谷哥大師用錯誤訊息查詢的結果,似乎是Chrome和nVidia驅動程式在Linux環境會出的BUG。




以LOG來看是Chrome在同時間開啟大量的檔案,導致超過系統允計的上限造成Chrome的頁面Crash。使用以下的指今可以看出現在系統允許每個USER能同時開啟的最大檔案數(Open files)是 1024,這是OS的自我保護機制。



# ulimit -a


core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 31647

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 1024

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited




可以先用指令的方式進行測試看看是不是真的是這個參數的影響(其實心裡已經認定是它了),因為這只是暫時性的修改而已。



# ulimit -Sn 4096

# ulimit -Hn 4096

    先用指令把參數值設定到4096(一次加到四倍,如果還不夠也太扯了),接著再用指令執行Chrome

# google-chrome




在開了一些常會跳掉的頁面後發現,真的OK了耶!

接下來就是修改設定檔,讓每次開機後設定都會生效!在參考連結的最下方有網友提到怎麼修改設定檔,但那是給Ubuntu用的。在Fedora環境下的# /etc/security/limits.conf 檔案裡有說明設檔案要怎麼用和設定檔放在/etc/security/limits.d目錄下, 以下說明Fedora的修改方式:

1. 在/etc/security/limits.d/ 目錄下建一個92-nofile.conf 檔案,內容如下


*        soft        nofile        4096

2. 重新開機


開機完後再用指令查詢

# ulimit -a

就會看到最大檔案開啟數量變成 4096 了,因為這原本就是保護機制,所以沒有必要別開太大,不然就失去了效果。 



core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 31647

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 4096

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 1024

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited



做了修改之後,Chrome就正常了,但這畢竟不是個正常的現象,檔案開啟數量超過1024,實在難以想像,還是希望能盡快改掉這個問題。




Fedora 20升級後的"Oh no! Something has gone wrong."登入畫面



  經過Fedup的漫長升級過程後,總算是見到了Fedora 20的登入畫面,但在登入原本自己的舊帳號後就發生悲劇了。在輸入密碼後,不是跳出美麗的桌面,而是一個"Oh no! Something has gone wrong."的Gnome錯誤訊息,然後就只能選擇Log Out,第一個想法是"該不會升級失敗了吧!!!"。不過開機過程和登入畫面看起來都挺正常的呀! 先用"Alt + Ctrl + F2"跳到純命列模式的consol界面繼續登入,幸好是可以登入的。


  因為懷疑是不是因為舊使用者的設定檔在新的環境中發生問題,所以試著用指令新增一個新使用者再來登入試看看。再切換回GUI模式用新使用者進行登入,竟然可以正常登入,這表示系統升級是成功的而且很有可能如我所猜測的一樣是舊環境設定的關係。進行一連串的google 查詢和各fedora論壇的衝浪,找到這篇討論。在新環境的 /usr/share/gnome-session/sessions/ 目錄下真的沒有 gnome-fallback.session 這個檔案,而其他的 gnome.session 是存在的。在之前的Fedora 18時,有將Gnome界面改回傳統界面,就是透過dConf editor將gnome的session-name改為gnome-fallback來調整的。如果系統中沒有gnome-fallback.session的檔案,那原本是這個設定值的帳號,將無法正常套用gnome的設定,於是就出現這個的錯誤了。



  至於為什麼Fedora 20會不能使用gnome-fallback這個設定值呢?那在Fedora 20裡的gnome又要如何改為傳統的界面呢?原來在Fedora 20裡的傳統界面可以透過套件整合在登入視窗的選項裡了,因此透過更改gnome設定值方式已不再使用了。在Fedora的論壇裡找到更改的方法,只要安裝 gnome-classic-session 套件就可以了。


  知道問題的發生原因就好處理了。一樣先用Alt + Ctrl + F2 切換到consol界面後,登入到要修正的帳號後,再用指令的方式把gnome-session修正為原來的值。指令如下:

 # dbus-launch gsettings set org.gnome.desktop.session.session-name gnome

這樣這個帳號就可以正確的進行登入畫面了。

再使用root權限安裝 gnome-classic-session套件,指令如下:

# yum install gnome-classic-session

安裝完成後,在登入畫面的中間偏下方一點處會有個齒輪,就可以選擇是要用新界面或是傳統界面來做登入後的操作界面了。





Fedora 18升級到Fedora 20

 


  Fedora在Fedora 18之後的升級方式有了變化,Fedora 17之前的版本是可以透過yum升級,但18之後的版本官方建議的方式是透過 fedup 來升級。可見參考連結,而且官方比較建議的升級媒介是透過網路取得套件,而並非光碟或是ISO檔。其實最主要的考量是透過網路可以直接更新為最新的套件,而且對使用者而言,最方便的是系統中之前透過yum安裝的套件只要有新系統可以用的套件也會一併更新,例如用yum安裝的那些從rpmfusion來的套件也能一併更新,超級方便。

 



  而官方的升級方式都是一個版本一個版本的往上升級,如果是像我一樣想要一次從Fedora 18升到20的話,其實也是可以的。不過系統升級最重要的其實是備份,所以在一切開始之前請千萬要記得備份資料,備份的方式就視每個人需要的備份程度而定了。

 



  在開始之前,官方有份資料最好可以先看一下,就是Fedora 20的已知bug,頁面上同時也列出解決方法,如果有遇到問題,可以先到這裡看一下。

 



  第一步先將現有的系統套件更新到最新版本,請指令視窗(終端機模式)指令如下:

# sudo yum update -y


 


  

  第二步,確認系統中是否已安裝 fedup ,如果不確定,直接下達安裝指令也可以,如果已經裝過了,系統會自動跳過。指令如下:

# sudo yum install fedup


 



  第三步,準備開始利用 fedup 升級吧,不過因為我們要升級的套件有可能是沒有簽章的套件,例如來自rpmfusion的套件,因此加上 --nogpgcheck 的參數!

# sudo fedup --reboot --network 20 --nogpgcheck



 


  接下來就是漫長的等待了(真的很久,上千個套件要下載和檢查,能不久嗎?),等待系統下載要升級的套件後,再確認套件的相依是否正確。最後才會開始進行系統的升級。

 



  如果發生套件有相依性的錯誤時,看看有問題的套件是那些,如果是比較不重要的套件,就先移除後再繼續升級。

 



Key word: Fedora 18 fedup upgrade




 


掛載 Synology 分享的 NFS 後無法使用 Gnome nautilus 無法寫入檔案

最近遇到一個奇怪的問題,我在 Fedora 的環境下 Mount Synology 分享出來的 NFS 空間時,發現 Gnome nautilus 檔案總管無法寫入或變更檔案就像沒有寫入權限一般。但若是使用 Shell 指令操作時,卻又一切正常。百思不得其解,在 google 了...