我在本教程中將介紹如何在各種桌面環境下,自動啟動某個程序。
GNOME桌面環境
在終端中運行這個命令,啟動"Startup Applications Preferences"(啟動應用程序首選項)GUI。
$ gnome-session-properties
點擊"Add"(添加)按鈕,即可配置一個新的啟動應用程序。分別往"Name"(名稱)欄和"Command"(命令)欄裡面鍵入該應用程序的名稱和該應用程序的CLI命令。往"Comment"(注釋)欄裡面鍵入可選的描述。
Unity桌面環境
在Unity Dash中鍵入"startup"(啟動)。一旦"Startup Application"(啟動應用程序)圖標出現,就點擊該圖標。
一旦"Startup Applications Preferences"(啟動應用程序首選項)窗口打開,輸入"Name"(名稱)、"Command"(命令)和"Comment"(注釋),即可配置自動啟動的某個程序。
KDE桌面環境
首先,打開"System Settings"(系統設置)窗口。你會在System Administration(系統管理)下面找到"Startup and Shutdown"(啟動和關閉)圖標。點擊該圖標。
系統會要求你從一系列已知的應用程序中選擇自動啟動的某個應用程序。如果你的程序沒有列出來,在上面空白區輸入該應用程序的名稱。如果該程序(比如CLI命令)將在終端中運行,就要選中"Run in terminal"(終端中運行)復選框。點擊"OK"(確定)按鈕。
下一步,系統要求你輸入該應用程序的詳細信息,包括名稱、命令和描述。
之後,你會看到該程序已完成配置,可自動運行。想配置額外的啟動程序/腳本,你可以點擊右邊側邊欄中的"Add Program"(添加程序)按鈕或"Add Script"(添加腳本)按鈕。
MATE桌面環境
在MATE桌面上,依次進入到"Applications"(應用程序)-> "Preferences(首選項)-> "Startup Applications"(啟動應用程序)。
你會看到"Startup Applications Preferences"(啟動應用程序首選項)窗口。點擊"Add"(添加)按鈕。
輸入啟動應用程序的詳細信息:"Name"(名稱)、"Command"(命令)和"Comment"(注釋)。
Xfce桌面環境
從Xfce桌面菜單中選擇"Settings Manager"(設置管理器)。在"Settings"(設置)窗口中,點擊"Session and Startup"(會話和啟動)圖標。
在"Application Autostart"(應用程序自動啟動)選項卡下,點擊底部的"Add"(添加)按鈕。
輸入自動啟動的某個程序的詳細信息:"Name"(名稱)、"Command"(命令)和"Description"(描述)。
LXDE桌面環境
想在LXDE桌面環境下配置啟動應用程序,只需在終端中運行下面幾個命令。
$ mkdir -p ~/.config/lxsession/Lubuntu/ $ touch ~/.config/lxsession/Lubuntu/autostart $ leafpad autostart
然後,把下面這一項添加到已創建的自動啟動文件中:
@conky
這里,"conky"是登錄後,我想自動運行的那個CLI命令的名稱。
保存並關閉。
B. linux中的session和終端有什麼聯系和區別
session 是會話的意思,一個連接就可以稱為會話,
終端一般指的是相對於伺服器的連接的客戶端,終端通過會話建立連接後,才和伺服器進行通訊,只要通信就有會話
C. 兩台linux伺服器如何實現weblogic跨伺服器session共享
Session共享有多種解決方法,常用的有四種:客戶端Cookie保存、伺服器間Session同步、使用集群管理、把Session持久化到資料庫。
1.客戶端Cookie保存
以cookie加密的方式保存在客戶端,每次session信息被寫在客戶端,然後經瀏覽器再次提交到伺服器,即使兩次請求在集群中的兩台伺服器上完成,也可以到達session共享。
優點是減輕伺服器端的壓力;
缺點是受到cookie的大小限制,可能佔用一定帶寬,因為每次請求會在頭部附帶一定大小的cookie信息,另外這種方式在用戶禁止使用cookie的情況下無效。
傳統網站一般通過將一部分數據存儲在cookie中,來規避分布式環境下session的操作。這樣做的弊端很多,一方面cookie的安全性一直廣為垢病,另一方面cookie存儲數據的大小是有限制的。隨著移動互聯網的發展,很多情況下還得兼顧移動端的session需求,使得採用cookie來進行session同步的方式的弊端更為凸顯,分布式session正是在這種情況下應運而生的。
2.伺服器間Session同步
定時同步各個伺服器的session信息,此方法可能有一定延時,用戶體驗也不是很好。
使用主-從伺服器的架構,當用戶在主伺服器上登錄後,通過腳本或者守護進程的方式,將session信息傳遞到各個從伺服器中,也可以手工把session文件存放的目錄改為nfs網路文件系統,從而實現文件的跨機器共享(使用nfs或windows文件共享都可以,或者專用的共享存儲設備)。
這樣,用戶訪問其它的從伺服器時,就可以讀到session信息。
缺點:比如速度慢、不穩定等,另外,如果session信息傳遞是主->從單向的,會有一些風險,比如主伺服器down了,其它伺服器無法獲得session信息。
3.把Session持久化到資料庫
這種共享session的方式即將session信息存入資料庫中,其它應用可以從資料庫中查出session信息。目前採用這種方案時所使用的資料庫一般為mysql。
利用資料庫共享session的方案有一定的實用性,但也有如下缺點:
首先session的並發讀寫在資料庫中完成,對mysql的性能要求比較高;
其次,我們需要額外地實現session淘汰邏輯代碼,即定時從資料庫表中更新和刪除session信息,增加了工作量。
對於系統可靠性要求較高的用戶,可以將session持久化到DB中,這樣可以保證宕機時會話不易丟失,但缺點也是顯而易見的,系統的整體吞吐將受到很大的影響。
4.使用集群管理Session
將session統一存儲在緩存集群上,如memcache,這樣可以保證較高的讀、寫性能,這一點對於並發量大的系統來說非常重要;並且從安全性考慮,session畢竟是有有效期的,使用緩存存儲,也便於利用緩存的失效機制。
使用緩存的缺點是,一旦緩存重啟,裡面保存的會話也就丟失了,需要用戶重新建立會話,可以使用緩存集群來保證緩存的穩定性。
如圖(基於緩存的分布式session架構)所示,前端用戶請求經過隨機分發之後,可能會命中後端任意的Web Server,將session以sessionid作為key,保存到後端的緩存集群中,使得不管請求如何分配,即便是某個Web Server宕機,也不會影響其他Web Server獲得 session,這樣既實現了集群間的session同步,又提高了 Web Server的容錯性。
Tomcat作為Web Server時,可以通過一個簡單的工具memcached-session- manager9(一個Tomcat session共享解決方案), 實現基於memcache的分布式session。
D. Linux如何啟動流程Linux啟動流程詳解
在BIOS階段,計算機的行為基本上被寫死了,可以做的事情並不多;一般就是通電、BIOS、主引導記錄、操作系統這四步。所以我們一般認為載入內核是linux啟動流程的第一步。
第一步、載入內核
操作系統接管硬體以後,首先讀入 /boot 目錄下的內核文件。
我們查看一下,/boot 目錄下面大概是這樣一些文件:
$ ls /boot config-3.2.0-3-amd64 config-3.2.0-4-amd64 grub initrd.img-3.2.0-3-amd64 initrd.img-3.2.0-4-amd64 System.map-3.2.0-3-amd64 System.map-3.2.0-4-amd64 vmlinuz-3.2.0-3-amd64 vmlinuz-3.2.0-4-amd64第二步、啟動初始化進程
內核文件載入以後,就開始運行第一個程序 /sbin/init,它的作用是初始化系統環境。
由於init是第一個運行的程序,它的進程編號(pid)就是1。其他所有進程都從它衍生,都是它的子進程。
第三步、確定運行級別
許多程序需要開機啟動。它們在Windows叫做"服務"(service),在Linux就叫做"守護進程"(daemon)。
init進程的一大任務,就是去運行這些開機啟動的程序。但是,不同的場合需要啟動不同的程序,比如用作伺服器時,需要啟動Apache,用作桌面就不需要。Linux允許為不同的場合,分配不同的開機啟動程序,這就叫做"運行級別"(runlevel)。也就是說,啟動時根據"運行級別",確定要運行哪些程序。
Linux預置七種運行級別(0-6)。一般來說,0是關機,1是單用戶模式(也就是維護模式),6是重啟。運行級別2-5,各個發行版不太一樣,對於Debian來說,都是同樣的多用戶模式(也就是正常模式)。
init進程首先讀取文件 /etc/inittab,它是運行級別的設置文件。如果你打開它,可以看到第一行是這樣的:
initdefault的值是2,表明系統啟動時的運行級別為2。如果需要指定其他級別,可以手動修改這個值。
那麼,運行級別2有些什麼程序呢,系統怎麼知道每個級別應該載入哪些程序呢?回答是每個運行級別在/etc目錄下面,都有一個對應的子目錄,指定要載入的程序。
/etc/rc0.d /etc/rc1.d /etc/rc2.d /etc/rc3.d /etc/rc4.d /etc/rc5.d /etc/rc6.d上面目錄名中的"rc",表示run command(運行程序),最後的d表示directory(目錄)。下面讓我們看看 /etc/rc2.d 目錄中到底指定了哪些程序。
$ ls /etc/rc2.d README S01motd S13rpcbind S14nfs-common S16binfmt-support S16rsyslog S16sudo S17apache2 S18acpid ...可以看到,除了第一個文件README以外,其他文件名都是"字母S+兩位數字+程序名"的形式。字母S表示Start,也就是啟動的意思(啟動腳本的運行參數為start),如果這個位置是字母K,就代表Kill(關閉),即如果從其他運行級別切換過來,需要關閉的程序(啟動腳本的運行參數為stop)。後面的兩位數字表示處理順序,數字越小越早處理,所以第一個啟動的程序是motd,然後是rpcbing、nfs......數字相同時,則按照程序名的字母順序啟動,所以rsyslog會先於sudo啟動。
這個目錄里的所有文件(除了README),就是啟動時要載入的程序。如果想增加或刪除某些程序,不建議手動修改 /etc/rcN.d 目錄,最好是用專門命令進行管理。
第四步、載入開機啟動程序
前面提到,七種預設的"運行級別"各自有一個目錄,存放需要開機啟動的程序。不難想到,如果多個"運行級別"需要啟動同一個程序,那麼這個程序的啟動腳本,就會在每一個目錄里都有一個拷貝。這樣會造成管理上的困擾:如果要修改啟動腳本,豈不是每個目錄都要改一遍?
Linux的解決辦法,就是七個 /etc/rcN.d 目錄里列出的程序,都設為鏈接文件,指向另外一個目錄 /etc/init.d ,真正的啟動腳本都統一放在這個目錄中。init進程逐一載入開機啟動程序,其實就是運行這個目錄里的啟動腳本。
下面就是鏈接文件真正的指向。
$ ls -l /etc/rc2.d README S01motd -> ../init.d/motd S13rpcbind -> ../init.d/rpcbind S14nfs-common -> ../init.d/nfs-common S16binfmt-support -> ../init.d/binfmt-support S16rsyslog -> ../init.d/rsyslog S16sudo -> ../init.d/sudo S17apache2 -> ../init.d/apache2 S18acpid -> ../init.d/acpid ...這樣做的另一個好處,就是如果你要手動關閉或重啟某個進程,直接到目錄 /etc/init.d 中尋找啟動腳本即可。比如,我要重啟Apache伺服器,就運行下面的命令:
$ sudo /etc/init.d/apache2 restart/etc/init.d 這個目錄名最後一個字母d,是directory的意思,表示這是一個目錄,用來與程序 /etc/init 區分。
第五步、用戶登錄
開機啟動程序載入完畢以後,就要讓用戶登錄了。
一般來說,用戶的登錄方式有三種:
(1)命令行登錄
(2)ssh登錄
(3)圖形界面登錄
這三種情況,都有自己的方式對用戶進行認證。
(1)命令行登錄:init進程調用getty程序(意為get teletype),讓用戶輸入用戶名和密碼。輸入完成後,再調用login程序,核對密碼(linux還會再多運行一個身份核對程序/etc/pam.d/login)。如果密碼正確,就從文件 /etc/passwd 讀取該用戶指定的shell,然後啟動這個shell。
(2)ssh登錄:這時系統調用sshd程序(linux還會再運行/etc/pam.d/ssh ),取代getty和login,然後啟動shell。
(3)圖形界面登錄:init進程調用顯示管理器,Gnome圖形界面對應的顯示管理器為gdm(GNOME Display Manager),然後用戶輸入用戶名和密碼。如果密碼正確,就讀取/etc/gdm3/Xsession,啟動用戶的會話。
第六步、進入 login shell
所謂shell,簡單說就是命令行界面,讓用戶可以直接與操作系統對話。用戶登錄時打開的shell,就叫做login shell。
linux默認的shell是Bash,它會讀入一系列的配置文件。上一步的三種情況,在這一步的處理,也存在差異。
(1)命令行登錄:首先讀入 /etc/profile,這是對所有用戶都有效的配置;然後依次尋找下面三個文件,這是針對當前用戶的配置。
~/.bash_profile ~/.bash_login ~/.profile需要注意的是,這三個文件只要有一個存在,就不再讀入後面的文件了。比如,要是 ~/.bash_profile 存在,就不會再讀入後面兩個文件了。
(2)ssh登錄:與第一種情況完全相同。
(3)圖形界面登錄:只載入 /etc/profile 和 ~/.profile。也就是說,~/.bash_profile 不管有沒有,都不會運行。
第七步,打開 non-login shell
老實說,上一步完成以後,Linux的啟動過程就算結束了,用戶已經可以看到命令行提示符或者圖形界面了。但是,為了內容的完整,必須再介紹一下這一步。
用戶進入操作系統以後,常常會再手動開啟一個shell。這個shell就叫做 non-login shell,意思是它不同於登錄時出現的那個shell,不讀取/etc/profile和.profile等配置文件。
non-login shell的重要性,不僅在於它是用戶最常接觸的那個shell,還在於它會讀入用戶自己的bash配置文件 ~/.bashrc。大多數時候,我們對於bash的定製,都是寫在這個文件裡面的。
你也許會問,要是不進入 non-login shell,豈不是.bashrc就不會運行了,因此bash 也就不能完成定製了?事實上,Debian已經考慮到這個問題了,請打開文件 ~/.profile,可以看到下面的代碼:
if [ -n "$BASH_VERSION" ]; then if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi fi上面代碼先判斷變數 $BASH_VERSION 是否有值,然後判斷主目錄下是否存在 .bashrc 文件,如果存在就運行該文件。第三行開頭的那個點,是source命令的簡寫形式,表示運行某個文件,寫成"source ~/.bashrc"也是可以的。
因此,只要運行~/.profile文件,~/.bashrc文件就會連帶運行。但是上一節的第一種情況提到過,如果存在~/.bash_profile文件,那麼有可能不會運行~/.profile文件。解決這個問題很簡單,把下面代碼寫入.bash_profile就行了。
if [ -f ~/.profile ]; then . ~/.profile fi這樣一來,不管是哪種情況,.bashrc都會執行,用戶的設置可以放心地都寫入這個文件了。
Bash的設置之所以如此繁瑣,是由於歷史原因造成的。早期的時候,計算機運行速度很慢,載入配置文件需要很長時間,Bash的作者只好把配置文件分成了幾個部分,階段性載入。系統的通用設置放在 /etc/profile,用戶個人的、需要被所有子進程繼承的設置放在.profile,不需要被繼承的設置放在.bashrc。
順便提一下,除了Linux以外, Mac OS X 使用的shell也是Bash。但是,它只載入.bash_profile,然後在.bash_profile裡面調用.bashrc,而且不管是ssh登錄還是在圖形界面里啟動shell窗口都是如此。
E. linux登陸session什麼意思
登錄是登錄,就是你用用戶名和密碼(當然可以無密碼,也可以無用戶名專,這個時候用的是默屬認,或者是上級用戶)。
session 是一個會話,准確的來說,就是你登錄後的那個狀態,這個狀態被一個進程保存。
這個進程會保持你的登錄狀態,同時運行其他的程序。而其他被運行程序因為是這個進程的子進程,也同時獲得了這個 session 進程的登錄狀態信息。
F. 怎樣讓linux啟動後不運行桌面而是運行自己寫的圖形界面程序
本文以redhat 8.0操作系統平台為背景,闡述如何實現啟動級別為3時的自動登錄,及自動運行相應程序,並簡要介紹了如何在redhat 8.0下自動登錄X window(系統啟動級別為5),並自動運行指定的應用程序。
一、啟動級別為3時自動登錄的實現
啟動級別為3時自動登錄的實現涉及兩個軟體包:mingetty-1.00-3.src.rpm軟體包及util-linux-2.11r-10.src.rpm軟體包。
(1)mingetty-1.00-3.src.rpm軟體包
對於啟動級別為3的自動登錄的實現,仍然需要考察/etc/inittab腳本,
3:123:respawn:/sbin/mingetty tty3
因此,如果想在啟動級別3的情況下實現自動登錄,必須要了解mingetty的功能,甚至要修改mingetty的代碼。用命令rpm -qf /sbin/mingetty 可知redhat 8.0版本的mingetty包含在mingetty-1.00-3.src.rpm軟體包中,下載該軟體包,安裝源代碼,預設情況下,代碼會安裝在/usr/src/redhat/下,我們關心的只是mingetty.c源文件。mingetty.c約有五百行代碼,主要實現如下功能:
打開指定的tty(由參數指定);
提示用戶登錄(login:);
獲得登錄用戶名;
把用戶登錄名作為參數,調用/bin/login。
我們所關心的部分實質上只有以下三行:
... ...
438 while ((logname = get_logname ()) == 0); //mingetty.c文件438行
439 execl (_PATH_LOGIN, _PATH_LOGIN, "--", logname, NULL);
440 error ("%s: can't exec " _PATH_LOGIN ": %s", tty, sys_errlist[errno]);
... ...
第一行的功能是輸出login提示,並獲得用戶輸入的登錄用戶名,登錄用戶名由logname返回。因此,可作如下修改
... ...
438 // while ((logname = get_logname ()) == 0); //注釋掉本行,不再提示login:
439 logname = "root"; //添加本行代碼
440 execl (_PATH_LOGIN, _PATH_LOGIN, "--", logname, NULL);
441 error ("%s: can't exec " _PATH_LOGIN ": %s", tty, sys_errlist[errno]);
... ...
注意,這里假定用戶以超級用戶身份登錄。
第二行以用戶登錄名為參數,調用/bin/login程序,進一步實現登錄。因此,要想實現自動登錄,還應該了解/bin/login的功能,必要時還應修改其源代碼。
第三行為出錯處理。
(2)util-linux-2.11r-10.src.rpm軟體包
採用同樣的方法,查看/bin/login所屬軟體包(redhad8.0版本的login包含在util-linux-2.11r-10.src.rpm軟體包中),下載並安裝util-linux-2.11r-10.src.rpm,login可執行文件有幾個源文件編譯而成,我們最關心的是login.c源文件(大約1500行的代碼)。下面簡要分析一下login要實現的功能,並對相應部分作必要的修改。
Login程序主要可以分為以下幾個主要部分:
1.Login首先檢查登錄者是否為超級用戶,如果不是超級用戶,並且存在/etc/nologin文件,則輸出該文件內容,並中止登錄過程;主要由checknologin()實現;
2.如果登錄用戶是超級用戶,那麼login必須在/etc/securetty/中指定的tty列表中實現登錄,否則將導致登錄失敗。同樣可以不指定/etc/securetty文件,此時,超級用戶可以在任何tty上登錄。
3.經過前兩步測試後,login接下來將提示輸入登錄密碼(由getpass()調用完成,有興趣的讀者可參考其手冊頁面),並進行驗證,如果密碼不對,則提示重新登錄。
4.順利經過密碼驗證後,login還將檢查是否存在.hushlogin文件,如果該文件存在,則執行一次"quiet"登錄(所謂的quiet登錄指的是,登錄時不再提示郵件mail,不再顯示最後一次登錄時間,不輸出任何消息。啟動級別為3時,正常情況下輸出這些信息)
5.login接下來設置登錄tty的用戶ID和組ID,並設置相應的環境變數,包括HOME、PATH、SHELL、TERM、LOGNAME等。對於普通用戶來說,PATH預設被設置成/usr/local/bin: /bin/usr/bin:;對於超級用戶來說,PATH被設置成/sbin: /bin: /usr/sbin: /usr/bin:
6.login的最後一步是為用戶啟動shell。如果在/etc/passwd中沒有為用戶指定shell,那麼將使用/bin/sh,如果在/etc/passwd中沒有給出當前工作目錄,則使用"/"。
至此,一個完整的登錄過程就結束了。
從以上對login源程序分析過程中可發現,如果要實現自動登錄,應該在第三步做文章,設法繞過提示輸入密碼以及對密碼進行驗證這一過程。實際上很簡單,login源程序對是否要求輸入密碼設置了一個開關控制passwd_req,預設情況下,其值為1(passwd_req = 1),即要求輸入密碼進行身份驗證。把該行代碼改為(passwd_req = 0)後,問題就解決了。即對源文件作如下修改即可:
... ...
402 fflag = hflag = pflag = 0; //login.c文件402行
403 //passwd_req = 1 //預設時,要求進行密碼驗證,注釋掉本行
404 passwd_req = 0 //添加本行
... ...
修改後,可以直接使用util-linux-2.11r-10.src.rpm提供的Makefile進行重新編譯,也可以自己對其編譯:
gcc -o login login.c setproctitle.c checktty.c xstrncpy.c -Wall -lcrypt注意包含後面的編譯選項-lcrypt,否則會出問題。
有了新版的mingetty及login後,拷貝mingetty到/sbin/目錄,拷貝login到/bin目錄,並將/etc/inittab中的啟動級別設置為3,再重新引導系統即可(讀者可以自己寫一個腳本實現上述過程)。
如果讀者對mingetty或login代碼的其他部分感興趣,可以反復修改login.c或mingetty.c的源代碼,測試一下代碼的功能,這里要注意的是,在拷貝新版mingetty和login之前,一定要把原來的mingetty和login備份,同時還要准備系統引導盤(有系統安裝盤亦可,這樣讀者有機會鍵入linux rescue),在測試新版程序前更應如此,如果對代碼修改稍有不當,系統將不能正常啟動。
如果不想再作進一步的代碼測試,只是按本文給出的方法進行代碼修改,在系統啟動上不會出現什麼問題。
二、自動登錄後,自動運行特定的應用程序
在實現了啟動級別3時的自動登錄後,自動運行應用程序非常簡單,把應用程序添加在/etc/rc.d/rc.local腳本中既可。(讀者可以嘗試一下把startx加入腳本中,看一看效果如何。在某種意義上,又增加了一種自動登錄X window的方法)
三、對自動登錄X window(系統啟動級別為5),並自動運行指定的應用程序的補充
在"如何實現自動登錄linux"中,主要以redhat 7.2平台為背景進行闡述的,其中的自動登錄部分可以直接用於redhat 8.0中,不需要任何修改。
但是,登錄後自動運行應用程序的介面在redhat 8.0中有所不同,主要是登錄gnome後,自動運行應用程序的介面有所改變:首先點擊面板上的GNOME幫助(那個紅色的小帽子),然後選擇/其它/首選項/Sessions,在Session對話框的啟動程序屬性頁中添加要啟動的程序即可。
對於登錄kde後,自動運行程序的介面沒有改變。
四、結論
本文同"如何實現自動登錄linux"一文,基本上解決了如何實現自動登錄Linux,並自動運行相應應用程序的問題。對於兩個最常見的啟動級別(3、5),都給出了各自的方法。
在系統初始化到mingetty及login這一階段,內核實際上已經完成了引導過程,已經到了系統初始化的最高階段,與內核沒什麼關系了。此時,主要是/sbin/init根據/etc/inittab的內容而相機行事。讀者可通過(man 8 init)或者(man 5 inittab)了解更多東西。
在對文中提到的軟體包修改時,請遵守GNU General Public License(GPL)相關標准,另外,替換login通常被視為黑客行為,應當謹慎行事。
參考文獻
1.login手冊頁面
2.mingetty-1.00-3.src.rpm,在redhat 8.0的發行版本的源代碼中,包含該軟體包;
3.util-linux-2.11r-10.src.rpm,
可在http://rpmfind.net/linux/RPM/redhat/8.0/i386/util-linux-2.11r-10.i386.html處下載,注意下載源代碼包(..src.rpm)
關於作者
鄭彥興,男,現攻讀國防科大計算機學院博士學位。您可以通過電子郵件 [email protected]和他聯系
G. Linux Ubuntu系統之PPP撥號經驗分享
pppd 撥號模塊,Linux系統是自帶的, 就像windows下自帶的RAS撥號一樣,列印機等很多應用需要通過撥號方式進行通信的。
參考文檔,配置4個文件:
這個事情,給我很大的啟示: 不要做戰略的矮子,再勤勞的執行力, 團隊的效率也上不來的。
上網搜索,多虧google,很快就明白了,SSH通過22埠,開啟了一個「session」,一般,如你執行 python3 main.py,隨著SSH Session結束,Linux會kill這個process的。 而這個PPP撥號程序需要作為一個長時間運行的,故需要用 nohup 和 & 關鍵字,這樣當你退出ssh,這個程序會駐留系統。
那麼問題來了,查詢運行的process,常用的 ps all就是不靈了。
要用 ps ax | grep py 才可以。
H. centos伺服器nginx怎麼開啟session
第一章 測試環境說明
1.1 系統說明
系統均選用最小化安裝的centos 5.7
1.2 軟體說明
nginx-0.8.55
pcre-8.13
apache-tomcat-6.0.35
jdk-6u31-linux-x64
nginx-upstream-jvm-route-0.1
1.3 規劃說明
客戶端通過訪問nginx做的負載均衡層去訪問後端的web運行層(tomcat),如下圖:
另外,關於session復制原理,簡單來說如下圖:
負載層:192.168.254.200
安裝:pcre、nginx、nginx-upstream-jvm-route-0.1
後端tomcat運行層:192.168.254.221、192.168.254.222
安裝:tomcat、jdk
第2章 安裝部署說明
2.1 負載均衡層安裝部署說明
2.1.1 依賴包安裝
yum install wget make gcc gcc-c++ -y
yum install pcre-devel openssl-devel patch -y
2.1.2 創建nginx運行帳號
useradd www -s /sbin/nologin -M
2.1.3 Pcre安裝
解壓pcre安裝包:tar xvf pcre-8.13.tar.gz
cd pcre-8.13
編譯pcre:./configure --prefix=/usr/local/pcre
安裝:make && make install
2.1.4 Nginx安裝
解壓nginx和nginx-upstream
tar xvf nginx-upstream-jvm-route-0.1.tar.gz
tar xvf nginx-0.8.55.tar.gz
cd nginx-0.8.55
配置jvmroute路徑:
patch -p0 < ../nginx_upstream_jvm_route/jvm_route.patch
編譯nginx:
./configure \
--user=www \
--group=www \
--prefix=/usr/local/nginx \
--with-http_stub_status_mole \
--with-http_ssl_mole \
--with-http_flv_mole \
--with-http_gzip_static_mole \
--pid-path=/var/run/nginx.pid \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp \
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp \
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp \
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp \
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp \
--add-mole=/root/scripts/src/nginx_upstream_jvm_route/
安裝:
make && make install
2.1.5 Nginx配置文件修改
Nginx作為負載的配置文件修改很簡單,只需添加後端web伺服器的ip及埠即可,修改運行帳號,下面配置文件中的紅色字體為本次測試環境的修改值;
user www www;
worker_processes 8;
#error_log logs/nginx_error.log crit;
#pid /usr/local/nginx/nginx.pid;
#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 51200;
events
{
use epoll;
worker_connections 2048;
}
http
{
upstream backend {
server 192.168.254.221:80 srun_id=real1;
server 192.168.254.222:80 srun_id=real2;
jvm_route $cookie_jsESSIONID|sessionid reverse;
}
include mime.types;
default_type application/octet-stream;
#charset gb2312;
charset UTF-8;
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 20m;
limit_rate 1024k;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
tcp_nodelay on;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
gzip on;
#gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
#limit_zone crawler $binary_remote_addr 10m;
server
{
listen 80;
server_name 192.168.254.250;
index index.jsp index.htm index.html;
root /data/www/;
location / {
proxy_pass http://backend;
proxy_redirect off;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
}
location ~ .*\.(js|css)?$
{
expires 1h;
}
location /Nginxstatus {
stub_status on;
access_log off;
}
log_format access '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
# access_log off;
}
}