linuxsuspend
㈠ 如何在Android 或linux 下，做Suspend /Resume 的Debug
常常使用console做為suspend function的debug的Information source，但原始的source code在suspend過程中，會將console關掉。
所以我們看到一定程度後就再也看不到message了。
但是我們並不知道在Suspend的過程中，系統到底發生了什麼事，可能造成無法suspend。
為此，我們就會在kernel 啟動參數中加上no_console_suspend這個參數。在AM/DM37x APM中是修改boot.scr檔案參數
㈡ linux下如何暫停一個進程
kill
-STOP
1234
將該進程暫停。
如果要讓它恢復到後台，用kill
-CONT
1234
（很多在前台運行的程序這樣是不行的）
如果要恢復到前台，請在當時運行該進程的那個終端用
jobs命令查詢暫停的進程。
然後用
fg
〔job號〕把進程恢復到前台。
如果jobs只查詢到一個進程，只用
fg
即可。
例：
root@dWorks:~#
bc
-q
[1]+
Stopped
bc
-q
root@dWorks:~#
bc
-q
[2]+
Stopped
bc
-q
root@dWorks:~#
jobs
[1]-
Stopped
bc
-q
[2]+
Stopped
bc
-q
root@dWorks:~#
fg
2
bc
-q
1+1
2
㈢ linux 如何立刻suspend usb
suspend:
#disableexternalwake-up;dothisonlyonce
echodisabled>/sys/bus/usb/devices/usb1/power/wakeup
echosuspend>/sys/bus/usb/devices/usb1/power/level#turnoff
wake up:
echoon>/sys/bus/usb/devices/usb1/power/level#turnon
根據你的實際情況修改usb1為usb n
㈣ Linux觸摸屏驅動中什麼時候會調用suspend這個函數
android系統摁下電源鍵後會讓系統進入休眠以達到節電的目的。內核驅動中和休眠相關的就是suspend和resume函數。
suspend函數用於休眠，resume函數用於喚醒。下面分析驅動中的這兩個函數是如何被調用到的。
驅動部分：
首先需要分析驅動的注冊過程，較新的內核都是採用DTS方式來取代在內核中直接定義platform_device數據結構的注冊方式，本文是基於DTS機制的內核來分析。
proct對應的dts文件在編譯時被編譯為dtb文件，uboot在啟動時候會將其地址傳給內核，內核在啟動過程中會去解析，具體解析是在start_kernel()->setup_arch() --> unflatten_device_tree()中具體分析可以參考網上，解析的最終結果會存放在allnodes地址處，這個allnodes隨後在machine的init函數
中被使用，init函數中會根據allnodes中的節點數據組合成platform_device數據結構，然後將其注冊到platform匯流排上，下面簡要分析一下並重點關注這些初始化過程中和
pm相關的初始化。
我參與的項目中machine的init函數就是via_init_machine函數，在這個函數中就是調用了of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL)這個函數來解析allnodes的。of_platform_populate是系統提供的介面。下面分析這個介面的實現：
[html] view plain
int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent)
{
struct device_node *child;
int rc = 0;
root = root ? of_node_get(root) : of_find_node_by_path("/");
if (!root)
return -EINVAL;
for_each_child_of_node(root, child) {
rc = of_platform_bus_create(child, matches, lookup, parent, true);
if (rc)
break;
}
of_node_put(root);
return rc;
}
root最後就是取到的根節點，然後其作為參數傳遞給of_platform_bus_create，of_platform_device_create_pdata的實現如下：
[html] view plain
static int of_platform_bus_create(struct device_node *bus,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent, bool strict)
{
const struct of_dev_auxdata *auxdata;
struct device_node *child;
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
int rc = 0;
/* Make sure it has a compatible property */
if (strict && (!of_get_property(bus, "compatible", NULL))) {
pr_debug("%s() - skipping %s, no compatible prop\n",
__func__, bus->full_name);
return 0;
}
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
platform_data = auxdata->platform_data;
}
if (of_device_is_compatible(bus, "arm,primecell")) {
of_amba_device_create(bus, bus_id, platform_data, parent);
return 0;
}
dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
if (!dev || !of_match_node(matches, bus))
return 0;
for_each_child_of_node(bus, child) {
pr_debug(" create child: %s\n", child->full_name);
rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict);
if (rc) {
of_node_put(child);
break;
}
}
return rc;
}
根據傳入參數，我們這里直接分析of_platform_device_create_padate函數，如下:
[html] view plain
struct platform_device *of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
struct device *parent)
{
struct platform_device *dev;
if (!of_device_is_available(np))
return NULL;
dev = of_device_alloc(np, bus_id, parent);
if (!dev)
return NULL;
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
#endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
*/
if (of_device_add(dev) != 0) {
platform_device_put(dev);
return NULL;
}
return dev;
}
of_platform_device_create_padate->of_device_alloc->platform_device_alloc
便在platform_device_alloc函數中進行進行alloc和初始化了，實現如下：
[html] view plain
struct platform_device *platform_device_alloc(const char *name, int id)
{
struct platform_object *pa;
pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
if (pa) {
strcpy(pa->name, name);
pa->pdev.name = pa->name;
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
}
可以看到有個device_initialize，這裡面對pdev.dev做一些列的初始化，其中有一個函數就是device_pm_init，這個函數就是我們一直關心的device相關的pm函數，具體實現如下：
[html] view plain
void device_pm_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
init_completion(&dev->power.completion);
complete_all(&dev->power.completion);
dev->power.wakeup = NULL;
spin_lock_init(&dev->power.lock);
pm_runtime_init(dev);
INIT_LIST_HEAD(&dev->power.entry);
dev->power.power_state = PMSG_INVALID;
}
可以看見它對device和功耗相關的數據做了一些初始化，我們這里先重點關注下dev->power.entry，初始化一個鏈表頭，所以他/它很有可能會在後面加到某個鏈表裡面去，而那個鏈表應該是用來保存所有的device用的。系統中所有的platform_device都是通過這種方式注冊到系統中的，那麼應該所有的platform_device都會初始化一個dev->power.entry，如果到時候把所有的dev->power.entry都添加到某個鏈表上去，那麼系統到時候查詢的時候只要找到這個list head就可以找到所有的platform_device了。嗯，不過這是我們的猜測。我們接下去分析來驗證下。
platform_device通過alloc之後已經初始化好了，那麼接下去就可以添加到系統中了，所以我們再回頭看of_platform_device_create_pdata的實現。
函數在of_device_alloc之後把dev->dev.bus賦值給了platform_bus_type，接著就調用了of_device_add函數，在of_device_add函數中最後通過device_add添加到了bus上，但是device_add中有個函數需要我們關系，就是device_pm_add(dev)，實現如下：
[html] view plain
void device_pm_add(struct device *dev)
{
pr_debug("PM: Adding info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
mutex_lock(&dpm_list_mtx);
if (dev->parent && dev->parent->power.is_prepared)
dev_warn(dev, "parent %s should not be sleeping\n",
dev_name(dev->parent));
list_add_tail(&dev->power.entry, &dpm_list);
dev_pm_qos_constraints_init(dev);
mutex_unlock(&dpm_list_mtx);
}
可以看到這里list_add_tail(&dev->power.entry, &dpm_list);這就驗證了我們之前的猜測。所有注冊到系統中的設備，最終都是會添加到dpm_list這條鏈表上。
那麼系統在休眠的時候是如何通過dmp_list這表鏈表來suspend設備的呢？接下去就是我們要分析的電源管理部分內容。
系統電源部分：
電源管理相關文件在kernel/power目錄下，前面已經分析到。系統中注冊的設備都是會添加到dmp_list這條鏈表上的。那麼睡眠的時候系統應該是會查找dmp_list這條鏈表，
然後通過這條鏈表依次去查到對應的driver，然後調用driver中的suspend方法。下面我們來驗證。
2.在suspend會輪詢bus下的driver，然後一次調用到driver->pm->suspend方法，然後進入休眠。
3.state_store->pm_suspend->enter_state->suspend_devices_and_enter->dpm_suspend_start->dpm_suspend->device_suspend->__device_suspend->pm_op->(ops->suspend)
㈤ 在linux中，qsub投任務，我想問一下這兩個狀態：pending和suspend 有什麼區別
通常情況下：
Pending是指任務在可以隨時運行，但是因為已經有任務在運行，所以排隊，這種狀態的任務可隨時進入運行態。
Suspend是被掛起的，在等待資源，等待的資源可以是輸入、信號或者硬體設備，在得到想要的資源後會轉成Pending狀態（如果有任務在運行）。
㈥ 如何在Android 或Linux 下，做Suspend /Resume 的Debug
在Linux或Android下，做power management 的調適時，常遇到沒有足夠的information，可以做為debug時的依據和參考
我們整理了幾個常用的參數或Command，可供設計者，得到足夠的Informaiton 做Suspend / Resume的function Debug。
加boot 參數 no_console_suspend
基本上我們常常使用console做為suspend function的debug的Information source，但原始的source code在suspend過程中，會將console關掉。所以我們看到一定程度後就再也看不到message了。
但是我們並不知道在Suspend的過程中，系統到底發生了什麼事，可能造成無法suspend。
為此，我們就會在kernel 啟動參數中加上no_console_suspend這個參數。在AM/DM37x APM中是修改boot.scr檔案參數
#!/bin/sh
cat <<EOF > boot.cmd
if fatload mmc 0 82000000 uImage
then
echo ***** Kernel: /dev/mmcblk0p1/uImage *****
fi
echo ***** RootFS: /dev/mmcblk0p2 *****
# Pantherboard DVI output
#setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi vram=32M omapfb.mode=dvi:1280x720MR-32 omapfb.vram=0:16M mpurate=1000'
# Pantherboard LCD output
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000'
將no_console_suspend加上去到boot 參數後就好了
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 no_console_suspend'
如果是OMAP4 APM的話，請修改Kernel 參數的所在檔案即可(在U-boot Source code中)
這個是基本的參數，所以在Android或Linux上都可以使用。 kernel把console suspend掉以後， 不管裡面出了什麼事情， 在Console上都看不到。 而使用這個參數後，大部分在suspend/resume時候的死機都可以通過Console看到kernel Panic的信息， 這樣我們才會知道是哪裡出了問題。 因為有的時候resume出錯， 或者suspend到很後面出錯的console不加這個參數都看不到。
但這個參數在TI OMAP3/OMAP4/AM37x/DM37x有可能造成有時Suspend 完當掉或是resume 失敗的問題，假如已經抓到問題在那的時候，您就可以將這個參數Disable，不然很可能就會Debug不下去。
initcall_debug
這個同樣kernel參數，使用的時機是，當我們不知道是那個driver在suspend/resume過程中出錯的時候，可以使用這個參數來找出問題所在。在下完這個參數後，Kernel在suspend時，會將每個driver或task的狀況report出來。我們可以藉由這些information，Check 在suspend時，每個task和driver是否已經完成進suspend 的相關准備工作…
打開這個參數的方法有二種
一種是在console下Command，啟動這個function…
echo 1 > /sys/mole/kernel/parameters/initcall_debug
echo 9 > /proc/sys/kernel/printk
其中上面的第一條命令是打開initcall_debug， 這個是所有的kernel都會有的。
而第二條命令是要提高kernel message 級別，因為initcall的這些信息都是KERN_DEBUG級別的， 所以需要提高printk的級別才可以看到， 要不然suspend/resume的時候掛了，你就沒有機會看到這些信息了。
另一種啟動方法是寫在kernel的啟動參數下，就可以了。
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 initcall_debug no_console_suspend'
同樣的，這個參數也有可能造成AM37x/DM37x/OMAP4 APM發生進suspend當掉的問題。所以一旦知道問題所在，麻煩請將這個參數Disable掉。
suspend_test
這個方法可以用rtc這種軟體的方式來做循環的suspend/resume， 盡管對於Android這樣並不是很足夠， （還要再模擬一個POWER_KEY上去才夠）， 但是對於測試Driver的穩定性， 還是有一定用處的。不要認為suspend了幾次可以，那麼就可以通過幾千次的測試。這個suspend是5秒鍾用RTC喚醒，然後回到Android後5秒鍾又會自動睡下去，但是對於通用Linux，你可以寫個script來讓他起來一會再睡下去，或許這個工具比較有用rtcwakeup（google rtcwakeup)。
使用方法：
編譯一個有這個功能的kernel， make menuconfig 以後選上
CONFIG_PM_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
這兩個選項，燒寫新的kernel，然後打開你需要測試的Device， 比如WIFI，3G
echo "core" > /sys/power/pm_test
echo "mem" > /sys/power/state
這樣， 它就會循環休眠和喚醒了。
wakelock
Android和Linux在Power Management相關的最大的就是wakelock機制的有無。Android有時候會碰到suspend進不去，或者suspend到最後又莫名奇妙的wake up的問題。這些都有可能是wakelock引起的，或者說是wakelock的使用者引起的。怎麼fine tune呢，使用Console在Android 系統下設定：
echo 15 > /sys/mole/wakelock/parameters/debug_mask
echo 15 > /sys/mole/userwakelock/parameters/debug_mask
15是代表16進制的F， 在wakelock裡面就是把所有的debug信息打開， 起碼現在是這樣設定的。如果以後不夠用了，可能就會改成255.
這樣你能看到kernel和frameworks層對於wakelock的操作、申請及釋放。這樣看申請和釋放成對否就可以了。
注意： wakelock有一種是timeout的，就是說多少毫秒以後，會自動釋放，對於這些wakelock，申請和釋放可能是不成對的。
power.0
有時看到系統suspend到了最後， 然後遇到power.0後suspend失敗，然後整個系統又resume回來。這個是android專有的，因為power.0是android注冊到suspend最後的一個行程， 它會在CPU進入suspend之前檢查一下有沒有wakelock存在， 如果這時候還有沒有釋放的wakelock， 那麼它會return -EBUSY然後導致整個suspend失敗。 Check這個問題的方法就是把上面wakelock的debug信息打開，然後看看是哪個去申請了wakelock，然後Release它。
這個錯誤的錯誤信息大概是這樣的：
pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11
PM: Device power.0 failed to suspend late: error -11
earlysuspend
在android裡面中另外一個和Power Management有相關的機制叫earlysuspend， 同樣可以打開debug message，用來做Android earlysuspend debug之用：
echo 15 > /sys/mole/earlysuspend/parameters/debug_mask
來把相關的debug信息印出來， 例如那個earlysuspend要被call之類的。
suspend/resume 時間 fine tune
有的時候你要調試suspend/resume的時間太慢的問題。 一種方法是用initcall_debug， 然後把printk的時間戳打上， 然後看那個process最慢，再來Check原因是什麼
我有一個patch，專門用來調試這個問題的，但是upstream不接受， 說非要用這種折磨人的方法才行， 但是如果你想用可以下下來打上去用一下。
地址在這里:http://www.spinics.net/lists/linux-pm/msg24063.html
用法是, 打上這個PATCH以後, 在KERNEL裡面選擇上PM_DEBUG， SUSPEND_DEVICE_TIME_DEBUG 這兩個選項。
然後
echo 微秒> /sys/power/device_suspend_time_threshold
比如
echo 50000 > /sys/power/device_suspend_time_threshold
注意這里是微秒哦。 。 。 它會把在suspend/resume的時候慢的那些driver打出來，然後你去幹掉它。 。
㈦ Linux裡面殺掉進程命令是什麼
方法一: Terminal終端輸入: gnome-system-monitor,就可以打開system monitor
如圖:
然後找到相應進程,右擊選擇kill process就可以了
方法二: 通過kill 進程id的方式可以實現,
首先需要知道進程id, 例如,想要殺死firefox的進程,通過 ps -ef|grep firefox,可以查到firefox的進程id:
然後通過 kill 3781 就可以關閉進程了.
補充: 1. kill -9 來強制終止退出, 例如: kill -9 3781
2.特殊用法：
kill -STOP [pid]
發送SIGSTOP (17,19,23)停止一個進程，而並不消滅這個進程。
kill -CONT [pid]
發送SIGCONT (19,18,25)重新開始一個停止的進程。
kill -KILL [pid]
發送SIGKILL (9)強迫進程立即停止，並且不實施清理操作。
kill -9 -1
終止你擁有的全部進程。
方法三: killall 通過程序的名字,來殺死進程
例如: killall firefox
注意: 該命令可以使用 -9 參數來強制殺死進程, killall -9 firefox
方法四: pkill 通過程序的名字, 直接殺死所有進程
例如: pkill firefox
方法五: 通過xkill 可以殺死圖形程序應用, 例如firefox崩潰無響應,可以使用該命令.
例如: 用法xkill , 會出現一個白色的x, 然後用滑鼠單擊想要殺死的應用,如圖
以下內容引用自: http://justcoding.iteye.com/blog/1931347
◆編者註：
KILLALL(Section: User (1)/Updated: 1999年9月7日)
———————————————–
NAME (名稱)
killall – 以名字方式來殺死進程
SYNOPSIS (總覽)
killall [-egiqvw] [-signal] name …
killall -l
killall -V
DESCRIPTION (描述)
killall 發送一條信號給所有運行任意指定命令的進程. 如果沒有指定信號名, 則發送SIGTERM.。
信號可以以名字 (如 -HUP ) 或者數字 (如 -1 ) 的方式指定. 信號 0 (檢查進程是否存在)只能以數字方式指定。
如果命令名包括斜杠 (/), 那麼執行該特定文件的進程將被殺掉, 這與進程名無關。
如果對於所列命令無進程可殺, 那麼 killall 會返回非零值. 如果對於每條命令至少殺死了一個進程, killall 返回 0。Killall 進程決不會殺死自己 (但是可以殺死其它 killall 進程)。
OPTIONS (選項)
-e
對 於很長的名字, 要求准確匹配. 如果一個命令名長於 15 個字元, 則可能不能用整個名字 (溢出了). 在這種情況下, killall 會殺死所有匹配名字前 15 個字元的所有進程. 有了 -e 選項,這樣的記錄將忽略. 如果同時指定了 -v 選項, killall 會針對每個忽略的記錄列印一條消息。
-g
殺死屬於該進程組的進程. kill 信號給每個組只發送一次, 即使同一進程組中包含多個進程。
-i
交互方式，在殺死進程之前徵求確認信息。
-l
列出所有已知的信號名。
-q
如果沒有進程殺死, 不會提出抱怨。
-v
報告信號是否成功發送。
-V
顯示版本信息。
-w
等待所有殺的進程死去. killall 會每秒檢查一次是否任何被殺的進程仍然存在, 僅當都死光後才返回. 注意: 如果信號被忽略或沒有起作用, 或者進程停留在僵屍狀態, killall 可能會永久等待。
FILES(相關文件)
/proc proc文件系統的存在位置。
KNOWN bugS (已知 BUGS)
以文件方式殺死只對那些在執行時一直打開的可執行文件起作用, 也即, 混雜的可執行文件不能夠通過這種方式殺死。
要警告的是輸入 killall name 可能不會在非 Linux 系統上產生預期的效果, 特別是特權用戶執行時要小心。
在兩次掃描的間隙, 如果進程消失了而被代之以一個有同樣 PID 的新進程, killall -w 偵測不到。
來源：http://www.ubuntuhome.com/ubuntu-kill-command.html
下面來了解相關命令：
一、查看進程的命令 有ps、pstree、pgrep等：
1、ps
顯示進程信息，參數可省略
-aux 以BSD風格顯示進程 常用
-efH 以System V風格顯示進程
-e , -A 顯示所有進程
a 顯示終端上所有用戶的進程
x 顯示無終端進程
u 顯示詳細信息
f 樹狀顯示
w 完整顯示信息
l 顯示長列表
在終端中執行ps aux,
各列輸出欄位的含義：
USER 進程所有者
PID 進程ID
PPID 父進程
%CPU CPU佔用率
%MEM 內存佔用率
NI 進程優先順序。數值越大，佔用CPU時間越少
VSZ 進程虛擬大小
RSS 頁面文件佔用
TTY 終端ID
STAT 進程狀態
+---D 不可中斷 Uninterruptible sleep (usually IO)
+---R 正在運行，或在隊列中的進程
+---S 處於休眠狀態
+---T 停止或被追蹤
+---Z 僵屍進程
+---W 進入內存交換（從內核2.6開始無效）
+---X 死掉的進程
+---< 高優先順序
+---N 低優先順序
+---L 有些頁被鎖進內存
+---s 包含子進程
+---+ 位於後台的進程組；
+---l 多線程，克隆線程 multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
PID:進程標識符，系統為每一個進程分配一個識別碼，稱為PID。
ps命令極為常用，其他命令還有：
2.pstree
樹狀顯示進程信息
-a 顯示完整命令及參數
-c 重復進程分別顯示
-c 顯示進程ID PID
-n 按 PID 排列進程
3.pgrep <進程名>
顯示進程的PID
-l 顯示進程名和進程PID
-o 進程起始ID
-n 進程終止ID
二、結束進程的命令 有kill、pkill、killall、xkill等：
kill [信號代碼] <進程PID>
根據PID向進程發送信號，常用來結束進程，默認信號為 -9
信號代碼，可取值如下：
-l [信號數字] 顯示、翻譯信號代碼
-9 , -KILL 發送 kill 信號退出
-6 , -ABRT 發送 abort 信號退出
-15 , -TERM 發送 Termination 信號
-1 , -HUP 掛起
-2 , -INT 從鍵盤中斷，相當於 Ctrl+c
-3 , -QUIT 從鍵盤退出，相當於 Ctrl+d
-4 , -ILL 非法指令
-11 , -SEGV 內存錯誤
-13 , -PIPE 破壞管道
-14 , -ALRM
-STOP 停止進程，但不結束
-CONT 繼續運行已停止的進程
-9 -1 結束當前用戶的所有進程
pkill <進程名>
結束進程族。如果結束單個進程，請用 kill
killall <進程名>
killall和pkill 應用方法差不多，也是直接殺死運行中的程序；如果您想殺掉單個進程，請用kill 來殺掉。
xkill
在圖形界面中點殺進程。
當xkill運行時滑鼠指針變為骷髏圖案，哪個圖形程序崩潰一點就OK了。如果您想終止xkill ，就按右鍵取消。
比如當firefox 出現崩潰不能退出時，點滑鼠就能殺死firefox 。
xkill 調用方法：
[root@localhost ~]# xkill
來源： http://www.cnblogs.com/1024-wusuopuBUPT/archive/2012/02/16/2354132.html
linux中pkill的簡單用法
pkill 和killall 應用方法差不多，也是直接殺死運行中的程序；如果您想殺掉單個進程，請用kill 來殺掉。
必要參數
-f 顯示完整程序
-l 顯示源代碼
-n 顯示新程序
-o 顯示舊程序
-v 與條件不符合的程序
-x 與條件符合的程序
選擇參數
-p<進程號> 列出父進程為用戶指定進程的進程信息
-t<終端> 指定終端下的所有程序
-u<用戶> 指定用戶的程序
應用方法：
#pkill 正在運行的程序名
舉例：
Java代碼
[root@localhost beinan]# pgrep -l gaim
2979 gaim
[root@localhost beinan]# pkill gaim
也就是說：
kill 對應的是 PID
pkill 對應的是COMMAND
例如在Ubuntu中強制結束一個已成僵屍的名稱為：firefox，PID為：1603的進程，可以如下操作：
方法一：
（1）ctrl+alt+t，調出終端，輸入 top，然後就可以看到現在系統的進程，是按佔用資源從多到少排列的。
找到要關掉的進程，記下該進程第一列的數字編號(假設是xx)，然後輸入q，退回終端。
（2）輸入：sudo kill xx(對應剛才的編號)。
方法二：
ctrl+alt+t，調出終端，輸入：sudo pkill firefox
範例1： 殺死指定進程
Java代碼
root@snail-hnlinux:~# ps -A //顯示所有進程
PID TTY TIME CMD
1 ? 00:00:03 init
2 ? 00:00:00 kthreadd
3 ? 00:00:00 migration/0
4 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 watchdog/0
……忽略部分
28382 ? 00:00:00 gvfsd-http
28391 ? 00:07:07 software-center
30467 ? 00:00:31 designer-qt4
30487 ? 00:00:06 gnome-terminal
30488 ? 00:00:00 gnome-pty-helpe
30489 pts/0 00:00:00 bash
30670 ? 00:00:00 debconf-communi
30749 pts/0 00:00:17 gedit
31155 ? 00:00:00 dhclient
31325 ? 00:00:01 sshd
31327 ? 00:00:00 sshd
31400 pts/1 00:00:00 bash
31485 pts/2 00:00:00 bash
3 ? 00:00:00 aptd
31658 pts/1 00:00:00 ps
root@snail-hnlinux:~# pidof sshd //查看與sshd相關進程
31327 31325 2095
root@snail-hnlinux:~# pkill -9 sshd //殺死指定進程
範例2：殺死同義終端下的進程
Java代碼
root@snail-hnlinux:~# pkill -t tty1 //殺死終端1下的所有進程
範例3： 殺死指定用戶進程
Java代碼
root@snail-hnlinux:~# pkill -u hnlinux
範例4：反向選擇
Java代碼
root@snail-hnlinux:~# pkill -vu hnlinux //殺死不屬於hnlinux用戶的所有進程
————————————————
版權聲明：本文為CSDN博主「MrCoderr」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/coderder/article/details/78899823
㈧ Linux 暫停命令
linux的暫停命令就是將進程殺死。
用一個實例說明：
1、首先使用tar命令打包/usr目錄：
進程恢復運行狀態（R）
㈨ Linux 暫停命令
是讓你指定內核頭文件。
要想停止安裝，可以用CTRL＋ALT＋F3這三個組合鍵，切換到另一個虛擬終端，ps
aux|grep
"configure"
命令找出這個進程號，然後kill
-9
這個進程號就可以殺死這個進程了。
個人建議用VirtualBox虛擬機，開源軟體，比VMWARE簡單易用。
㈩ linux下如何暫停一個進程
kill -STOP 1234 將該進程暫停。
如果要讓它恢復到後台，用kill -CONT 1234 （很多在前台運行的程序這樣是不行的）
如果要恢復到前台，請在當時運行該進程的那個終端用
jobs命令查詢暫停的進程。
然後用 fg 〔job號〕把進程恢復到前台。
如果jobs只查詢到一個進程，只用 fg 即可。
例：
root@dWorks:~# bc -q
[1]+ Stopped bc -q
root@dWorks:~# bc -q
[2]+ Stopped bc -q
root@dWorks:~# jobs
[1]- Stopped bc -q
[2]+ Stopped bc -q
root@dWorks:~# fg 2
bc -q
1+1
2