[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




 


[Fedora 18]Firewalld在純script環境下的bug


     在Fedora的系統中,預設的防火牆已由iptable改為Firewalld了。Firewalld有較為優良的GUI設定界面,在剛開始還蠻容易上手。在使用一段時間後,發現一個問題。因為我的PC並不是一直開著機,而是有要用到時,再透過遠端開機的方法將PC開起來使用。一直以來用iptable也都沒發生什麼問題,自從開始使用Firewalld之後,常會發生將電腦開機後,透過ssh的方式連回家使用,有時會發生SSH無法正常連線,或是剛開機時可以正常連線,但使用一會兒之後就會斷線就無法連線了。幾番確認之後,確定問題出在防火牆。趁這幾天有空到各大論譠和Fedora的官網中看看有沒有什麼已知的問題,總算在官網中對Firewalld的說明中找到一段很重要的字句,也說明了為什麼會突然不通的原因。







原來官方早就知道這個問題,而且在Fedora 19中還沒解決,突然覺得似乎換回iptable,雖然設定上較麻煩,但可控性比較高。

[Fedora 18]能執行line的wine版本

  之前使用wine 執行PC版的LINE都還蠻正常的,不過前幾天更新了wine之後,反而無法使用了。


  目前遇到情況的環境是  Fedora 18 64bit. 追了一下情況發現,之前正常使用的wine版本是1.5.20,更新到wine 1.5.25後反而就不能用了。


  如果也有在linux下使用line的朋友,稍微注意一下,若你的line在系統更新之後就無法使用,可以試著將wine降回到1.5.20。


  如果不想直接降版本,可以考慮用PlayOnLinux來製作和管理多個wine版本的環境(但硬碟會吃比較兇哦)!


[Fedora 18]恢復傳統的Gnome界面

  在Fedora 18中預設的Gnome是版本3.6的,和之前的傳統式界面是差很多的,最新的界面可以參考這裡


  但在下實在不太習慣這新的界面,還是想回到之前舊的傳統界面,而舊的傳統界面仍在存在於系統之中,只是要做某些設定就能回去了(這次不是回不去了)。為了避免在繁雜的設定檔間遊走,裝個小工具,透過工具來做修改就容易很多了。


  首先安裝dconf-editor套件,可以透過gpk-application來安裝或是直接使用指令來進行安裝。透過圖形界面安裝的方式就沒有什麼特別的要說明了,在這裡提一下安裝的指令:


# yum install dconf-editor



安裝完成後,按下 Alt + F2,執行 dconf-editor ,就會看到協助修改的工具。

用法很像在windows下使用regedit,以階層式的列出系統設定值,因為列出來的設定值很多,所以如果不清楚用途的話,千萬不要亂改。

接著在 “org > gnome > desktop > session“ 階層下找到 session-name 這個屬性

將其中的gnome改為gnome-fallback,然後登出後再重新登入就會看到懷念的桌面了。


操作步驟可以參考影片

[Fedora 18]系統更新

  不論用的是什麼OS,不管再如何嚴謹都總是會有BUG或漏洞。因此更新也就是必然也是必需的作業,在Fedora的世界裡,預設是使用RPM套件管理員來管理軟體套件,透過YUM來協助處理RPM套件相依性的問題。習慣使用指令模式的朋友,可以透過gnome-terminal下達YUM的指令來進行更新。指令如下:


# sudo yum update


系統就會針對現行已經安裝過的套件做更新檢查,若有發現可以更新的檔案,就會表列出來,最後再確認是否安裝就可以了。



透過圖形界面的方式可以按 Alt + F2調出執行功能,輸入gpk-application,調出程式或是參考影片


Docker SIGILL: illegal instruction 問題除錯記錄

Docker SIGILL: illegal instruction 問題除錯記錄 最近在一台平常執行得好好的伺服器上,遇到一個讓人頭痛的 Docker 問題。 原本 Portainer 和其他容器都可以正常運行,但在系統突然當機後,所有容器在啟動時都出現以下錯誤訊息: d...