2014-05-13 19:02:03 heiworld 阅读数 1219
  • Linux系统编程、网络编程》第6章 信号

    课程内容: 学习本章的意义、Linux下都有哪些信号、signal函数、子进程对父进程信号的集成情况、kill、raise、alarm、pause、abort函数、信号休眠函数的唤醒、信号的发送、接收和处理的过程、如何调用API修改信号的屏蔽字。

    328 人正在学习 去看看 张先凤

      kill系统调用以前一直认为只是用来杀死某个进程的,看了源码纠正下自己的错误认识。源码如下:

int sys_kill(int pid,int sig)
{
	struct task_struct **p = NR_TASKS + task;
	int err, retval = 0;

	if (!pid) while (--p > &FIRST_TASK) {
		if (*p && (*p)->pgrp == current->pid) 
			if (err=send_sig(sig,*p,1))
				retval = err;
	} else if (pid>0) while (--p > &FIRST_TASK) {
		if (*p && (*p)->pid == pid) 
			if (err=send_sig(sig,*p,0))
				retval = err;
	} else if (pid == -1) while (--p > &FIRST_TASK)
		if (err = send_sig(sig,*p,0))
			retval = err;
	else while (--p > &FIRST_TASK)
		if (*p && (*p)->pgrp == -pid)
			if (err = send_sig(sig,*p,0))
				retval = err;
	return retval;
}

分析:主要分成4个判断。
①pid为0,则向每一个进程组号为当前进程pid的进程发送该信号
②pid>0,向该进程号发送信号
③pid=-1,向除0号进程外的所有进程发送信号
④pid<-1,向进程组号为-pid的进程发送信号
另外在第一种情况里面调用的是send_sig(sig,*p,1),而其他调用的是send_sig(sig,*p,0)。再来挖一下参数0和1的区别,下面是send_sig()的函数源码:

static inline int send_sig(long sig,struct task_struct * p,int priv)
{
	if (!p || sig<1 || sig>32)
		return -EINVAL;
	if (priv || (current->euid==p->euid) || suser())
		p->signal |= (1<<(sig-1));
	else
		return -EPERM;
	return 0;
}

这种代码主要表述的是在什么情况下当前进程能向其他进程发送信号,有3中情况,满足任意一种即可。
①priv=1,这个变量代表强制发送信号的标志,当它为1时,则不需要考虑进程用户属性或级别,它都有权发送信号。结合到kill的代码里面,也就是说kill调用中的参数pid=0的时候才会强制发送信号
②当前进程的有效用户标识符就是指定进程的标识符,也就是说就是自己
③超级用户

2012-05-18 01:27:26 liranke 阅读数 6380
  • Linux系统编程、网络编程》第6章 信号

    课程内容: 学习本章的意义、Linux下都有哪些信号、signal函数、子进程对父进程信号的集成情况、kill、raise、alarm、pause、abort函数、信号休眠函数的唤醒、信号的发送、接收和处理的过程、如何调用API修改信号的屏蔽字。

    328 人正在学习 去看看 张先凤

再谈“如何学习和理解Android源码”

一. 引子

对于Android源码,网上很多文章都只是列了整个源码的目录结构,这样,习惯性地就将读者引导到按照文章目录结构去阅读的道路上了。而在这篇文章中,贯穿的主线是“进程”,这其实也不难理解,因为计算机中唯一的活着的东西就是“进程”,所以才有kill命令。另外,要阅读的时候,要注重理解系统,而不仅仅是代码,当笔者阅读代码的时候,常常有这种感觉,陷入“惊叹于代码如何如何优美”,而忽略了去更加深入理解系统。另外,之所以称这篇文章为再谈,是因为之前(想想看,已经是3年前的事情了)的一篇博文“Android 启动过程”中已经按照“进程”这个思路大概分析了一下Android 启动过程了。想看的朋友,最好下载资源Android初始化流程:

http://download.csdn.net/detail/liranke/2037956

而本篇的目的,并不是真正地去分析Android源码,而是试图使读者从另外一个角度去学习和理解Android源码,这也正切合了标题的“如何”二字。

二. 一个进程列表的分析

好了,正式开始我们的“进程”之旅。

关于进程的概念,相信不用在这里繁述了,下面,是用ps命令列出的Android的一个进程列表,这个列表是从真机中而非虚拟机中获得的:

USER     PID   PPID  VSIZE RSS   WCHAN    PC         NAME
root     1     0     548   196   c00b8c14 0000d5cc S /init
root     2     0     0     0     c006bf70 00000000 S kthreadd
root     3     2     0     0     c005cc50 00000000 S ksoftirqd/0
root     4     2     0     0     c007e408 00000000 S watchdog/0
root     5     2     0     0     c0068eec 00000000 S events/0
root     6     2     0     0     c0068eec 00000000 S khelper
root     10    2     0     0     c0224f90 00000000 S suspend/0
root     81    2     0     0     c0068eec 00000000 S kblockd/0
root     89    2     0     0     c01f2f7c 00000000 S kseriod
root     111   2     0     0     c0068eec 00000000 S kmmcd
root     117   2     0     0     c0068eec 00000000 S btaddconn
root     118   2     0     0     c0068eec 00000000 S btdelconn
root     135   2     0     0     c00448e0 00000000 S bpmd
root     141   2     0     0     c008b5f4 00000000 S pdflush
root     142   2     0     0     c008b5f4 00000000 S pdflush
root     143   2     0     0     c008f948 00000000 S kswapd0
root     189   2     0     0     c0068eec 00000000 S aio/0
root     195   2     0     0     c01721f0 00000000 S mtdblockd
root     340   2     0     0     c01b4eb0 00000000 S accessory notif
root     349   2     0     0     c0068eec 00000000 S camera_task/0
root     376   2     0     0     c0061438 00000000 S w1_control
root     378   2     0     0     c0061438 00000000 S w1_bus_master1
root     386   2     0     0     c0068eec 00000000 S charge
root     428   2     0     0     c02ca26c 00000000 S krfcommd
root     430   2     0     0     c0068eec 00000000 S rpciod/0
root     724   2     0     0     c0216908 00000000 S mmcqd
root     726   1     772   180   c019dbc4 afe0c1dc S /system/bin/sh
system   727   1     840   188   c022d8a0 afe0c47c S /system/bin/servicemanager
root     729   1     1920  336   ffffffff afe0c1dc S /system/bin/mountd
root     730   1     704   176   c0257854 afe0ce0c S /system/bin/debuggerd
root     731   1     4132  628   c027e2f8 afe0ce0c S /opl/bin/tcmd
root     732   1     852   248   c00b92b0 afe0c5a4 S /opl/bin/adapter
radio    733   1     12796 648   ffffffff beaab18c S /system/bin/rild
root     734   1     72000 14172 c00b92b0 afe0c5a4 S zygote
root     735   1     33848 4512  ffffffff afe0c47c S /system/bin/mediaserver
root     736   1     1080  216   c00b8c14 bedc021c S /system/bin/dbus-daemon
root     737   1     832   208   c02b6e80 afe0c1dc S /system/bin/installd
root     740   1     856   260   c00b92b0 afe0c5a4 S /opl/bin/bpd
root     741   1     828   172   c00b8c14 afe0d27c S /opl/bin/battmond
root     768   1     720   272   c02265ec afe0c1dc S /system/bin/logcat
root     769   1     716   264   c02265ec afe0c1dc S /system/bin/logcat
root     816   2     0     0     c0068eec 00000000 S battery.0
system   825   734   574128 28360 ffffffff afe0c47c S system_server
radio    877   734   158260 20040 ffffffff afe0d404 S com.android.phone
app_5    879   734   100888 13616 ffffffff afe0d404 S android.process.acore
system   882   734   144664 24296 ffffffff afe0d404 S android.process.omsservice
app_45   884   734   92304 10932 ffffffff afe0d404 S com.motorola.motohome
app_22   890   734   117068 30228 ffffffff afe0d404 S oms.home
app_3    918   734   98760 12652 ffffffff afe0d404 S oms.widgetmanager
app_5    928   734   100888 13336 ffffffff afe0d404 S com.android.inputmethod.borqs
app_24   930   734   105176 19168 ffffffff afe0d404 S com.db4o.servo.search
app_18   960   734   104180 15208 ffffffff afe0d404 S com.android.mms
app_8    979   734   118860 14044 ffffffff afe0d404 S android.process.media
app_9    991   734   91980 12264 ffffffff afe0d404 S com.android.alarmclock
app_15   998   734   103144 12908 ffffffff afe0d404 S oms.dcd
system   1018  734   94732 13792 ffffffff afe0d404 S oms.dm
app_14   1025  734   95636 13036 ffffffff afe0d404 S com.android.calendar
app_42   1041  734   93292 11316 ffffffff afe0d404 S com.motorola.smsautoreg
app_40   1090  734   97152 15192 ffffffff afe0d404 S com.motorola.mtc
app_38   1102  734   93832 12868 ffffffff afe0d404 S com.streamezzo.browser.android
app_26   1115  734   96596 15084 ffffffff afe0d404 S oms.mediacenter
app_37   1126  734   98208 15212 ffffffff afe0d404 S com.hyfsoft.docviewer
app_20   1146  734   99260 15320 ffffffff afe0d404 S com.android.music
app_47   1157  734   100204 15964 ffffffff afe0d404 S com.motorola.camera
app_11   1183  734   122672 23576 ffffffff afe0d404 S com.android.browser
app_6    1199  734   117032 20388 ffffffff afe0d404 S oms.mobilemusic
system   1244  734   99292 15940 ffffffff afe0d404 S com.android.settings
app_23   1311  734   96932 16004 ffffffff afe0d404 S oms.bru
root     1334  2     0     0     c0216908 00000000 S mmcqd
app_8    1351  734   100308 15876 ffffffff afe0d404 S com.android.camera
app_1    1424  734   111904 17024 ffffffff afe0d404 S oms.messaging
app_4    1436  734   101172 15504 ffffffff afe0d404 S oms.mail
app_2    1484  734   100716 18128 ffffffff afe0d404 S com.ms
app_16   1663  734   101024 16748 ffffffff afe0d404 S oms.android.filemanager
root     1684  1     3364  176   ffffffff 0000e8f4 S /sbin/adbd
root     1692  1684  776   348   c0059cd4 afe0d0ac S /system/bin/sh
root     1724  1692  920   356   00000000 afe0c1dc R ps

OK,让我们看看这个长长的列表包含了些什么信息吧:
1. 大家知道,linux系统中,init的pid是就是1,而且它是linux内核启动之后的第一个进程,而它的

ppid(父进程)是0,这也表明,0也是个一个进程。事实上,linux内核的pid就是0。
2. pid 为2的进程是kthreadd,而它的父进程也是内核(pid为0的进程),这个进程和它的子进程(诸如

ksoftirqd之类的ppid为2的进程)一起,可以处理包含但不限于内核cpu调度或者事件处理的一些功能。
3. 接下来,我们看到的了一系列以ppid为1的进程,包括我们熟悉的sh,servicemanager,

mountd,rild,zygote,mediaserver,logcat等等。它们的父进程是init,仔细阅读init的代码,就会发

现,其实,这些是在init.rc中指定的。另外,以上这些进程,都是一些C/C++代码写的,事实上,这时

候,java虚拟机(jvm)还没有启动,所以,现在根本不能运行java代码,也谈不上Android framework,

 而至于Activity之类的,系统根本不知道是什么东东。后面,会着重介绍servicemanager,zygote。

而其它的,读者可以自己分析。
4. 从system_server开始,包括系统自己带的android应用程序,以及用户实现的android应用程序,它

们的父进程都是zygote。我们知道,每一个android应用程序都是一个jvm,所以,读者可以猜想,

zygote中会进行java虚拟机的装载以及runtime的初始化。另外,整个进程列表中,并没有看到Android

Framework相关的进程列表。事实上,读者的想法一点没有错,zygote初始化了jvm,而system_server就

是Android Framework组件的进程所在。因此,毫不夸张地说,zygote和system_server是Android 

Framework的基石。
5. 那么,上面这个进程列表是如何产生的。看最后三行,不难理解,我们从adbd 启动了一个shell,然

后,输入ps命令,就得到了上面这个进程列表。
6. 另外,从第一列USER(用户)的用度看,所有的Android应用程序(包括系统自带的)都是app_XXX,

熟悉Android应用程序开发的读者也知道,每一个Android应用程序都是独立的,有自己的UID。
7. 事实上,如果将上面所有的进程(特别是用户为root, sysytem)都理解了的话,那么,也就相当于

理解了Android系统。
8. 从以上列表,你还想到了什么?

三. 进程/system/bin/servicemanager:

1. servicemanager是一个可执行程序,代码位于:frameworks/base/cmds/servicemanager;
2. servicemanager是init通过init.rc加载的第一个进程;
3. 查看servicemanager的原码(service_manager.c),最重要的一句:binder_open(128*1024); 哦,我们看到了binder,而且它申请的内存空间是128*1024。正是有了servicemanager,系统的service和用户自己开发的service才可以正常运行;
4. 可以想到的是,binder是在servicemanager中进行数据结构的初始化,并打开了"/dev/binder"。


四. 进程zygote:
1. 代码位置:frameworks\base\core\java\com\android\internal\os
2. 主要作用:
    creat Jvm->fork SystemServer->start system_server

3. 详细请参考: Android初始化流程:

http://download.csdn.net/detail/liranke/2037956

 

五. 进程system_server

1. 代码位置:frameworks\base\services\java\com\android\server:
2. 主要作用:初始化核心组件,事实上,就是Android framework层的组件,例如,POWER_SERVICE,ActivityManagerService,PackageManagerService,batteryService,LightsService,VibratorService,AlarmManagerService,WindowManagerService......,这些组件,大部分都是以service的形式存在的。正是因为如此,我们才可以在这些组件的基础上进行应用程序的开发。所以,frameworks\base\core\java\com\android\internal\os\SystemServer.java这个文件是必须要仔细看的,事实上,这个文件本身的代码结构是非常简单的。

3. 至此,已经到了Android framework层了,剩下的就是那些组件各自的功能了,例如ActivityManagerService,PackageManagerService,WindowManagerService......

六. 后记

通过以上分析,我们就基本了解了Android的系统架构为什么是现在这个样子了。另外,在这个基础之上,如果感兴趣的话,再去分析和理解binder机制,adbd等,就会对系统更加熟悉了。祝读者在Android领域中展现出自己独特的风采!

 

 

 

 

 

2016-11-19 13:18:27 OneGoal 阅读数 717
  • Linux系统编程、网络编程》第6章 信号

    课程内容: 学习本章的意义、Linux下都有哪些信号、signal函数、子进程对父进程信号的集成情况、kill、raise、alarm、pause、abort函数、信号休眠函数的唤醒、信号的发送、接收和处理的过程、如何调用API修改信号的屏蔽字。

    328 人正在学习 去看看 张先凤

服务分类

linux服务分为rpm包默认安装的服务和源码包安装的服务。
rpm包默认安装的服务分为独立的服务和基于xinetd服务。

查询已安装的服务

rpm包安装的服务
    chkconfig --list          #查看服务自启动状态,可以看到所有rpm包安装的服务
源码包安装的服务
    查看服务安装位置:一般是/usr/local/下

rpm安装的服务和源码安装的服务的区别是安装位置的不同。


安装xinetd与telnet

yum -y install xinetd
yum -y install telnet-server   #xinetd不安全,用的不多了。学习时候可以安装了以后再进行学习和测试。

目录 描述
/etc/ 配置文件目录
/etc/init.d/ 启动脚本位置
/etc/sysconfig/ 初始化环境配置文件位置
/etc/xinetd.conf xinetd配置文件
/etc/xinetd.d 基于xinetd服务的启动脚本
/var/lib/ 服务产生的数据放在这里
/var/log/ 日志
/usr/bin 可执行命令安装目录
/usr/lib 程序所用的函数库保存位置
/usr/share/doc 软件使用手册保存位置
/usr/share/man 帮助文件保存位置
/etc/rc.d/init.d 启动文件保存位置

独立服务的启动

/etc/init.d/独立服务名 start|stop|status|restart
service 独立服务名 start|stop|status|restart

service –status-all
查看所有的rpm包服务状态

独立服务的自启动

第一种:chkconfig [--level 运行级别][独立服务名][on|off]

第二种:修改文件/etc/rc.d/rc.local   加入 /etc/init.d/httpd start

第三种:使用ntssysv命令管理自启动   (redhat独有)

xinetd服务的启动

vi /etc/xinetd.d/telnet
service telnet                       #服务的名称为telnet
{
    flag=REUSE                       #标志为REUSE,设定TCP/IP socket可重用
    socket_type=stream               #使用TCP协议数据包
    wait=no                          #允许多个连接同时连接
    user=root                        #启动服务的用户为root
    server=/usr/sbin/in.telnetd      #服务的启动程序
    log_on_failure += USERID         #登录失败后,记录用户的ID
    disable = yes                    #服务是否启动,no为启动 
}



service xinetd restart               #重启xinetd restart

xinetd服务的自启动

第一种:chkconfig telnet on|off

第二种:ntsysv

xinetd启动和自启动会同步。可能这就是他不怎么用的一个原因吧。

源码包服务的启动

/usr/local/apache2/bin/apachectl start|stop     #查看源码包安装文件,找到启动脚本的方法

源码包服务的自启动

vi /etc/rc.d/rc.local
/usr/local/apache2/bin/apachctl start

让源码包服务被服务管理命令识别

ln -s /usr/local/apache2/bin/apachectl /etc/init.d/apache    #让源码包的apache服务能被service命令管理启动


vi /etc/init.d/apache                  #让源码包能被chkconfig和ntsysv命令管理自启动
# chkconfig:35 86 76                   #指定httpd脚本可以被chkconfig命令管理。格式是:chkconfig:运行级别 启动顺序 关闭顺序
# description: source package apache   #说明:内容随意

服务和作用

这里写图片描述
这里写图片描述
这里写图片描述
这里写图片描述
这里写图片描述

ps

ps aux                 #a 前台进程     x后台进程     u哪个用户生成的
ps -efl                #e所有进程      l更详细的信息  f表达进程之间的关系



USER     PID    %CPU  %MEM    VSZ   RSS   TTY    STAT    START    TIME    COMMAND
root     9617   0.0    0.1  110244  1148 pts/1    R+     12:07    0:00    ps aux

#USER          哪个用户产生的
#PID           进程id
#%CPU          占用cpu资源百分比
#%MEM          占用内存资源百分比
#VSZ           占用虚拟内存大小   大小KB
#RSS           占用那个物理内存大小   KB
#TTY           该进程在哪个终端中运行   tty1-tty7本地控制台终端,其中tty7为图形终端,其他字符终端,pts/0-pts/256代表虚拟终端
#STAT          进程状态  R运行,S睡眠,T停止状态,s包含子进程,+位于后台
#START         进程启动时间
#TIME          占用cpu运行时间
#COMMAND       产生此进程的命令

top

[root@localhost 12:23:33 Desktop]# top

top - 12:25:24 up 6 min,  2 users,  load average: 4.68, 3.24, 1.48
Tasks: 157 total,   2 running, 155 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.8%us,  1.7%sy,  0.0%ni, 91.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1004132k total,   621724k used,   382408k free,    25888k buffers
Swap:  1048572k total,        0k used,  1048572k free,   240808k cached

/************
第一行:
12:25:24            系统当前时间
up 6 min,           系统运行时间,本机已经运行6分钟
2 users,            当前系统登录了两个用户
load average: 4.68, 3.24, 1.48       系统在之前1分钟,5分钟,15分钟的平均负载。一般以cpu核数为界限
*************/



/************
第二行:
Tasks: 157 total,              系统进程总数    
2 running,                     正在睡眠的进程数  
155 sleeping,                  正在运行的进程数
0 stopped,                     正在停止状态的进程数
0 zombie                       僵尸进程,如果非0,手工检查僵尸进程
*************/







/************
第三行:
Cpu(s):6.8%us,     用户模式下占用cpu百分比  
1.7%sy,            系统模式下占用cpu百分比
0.0%ni,            改变过优先级的用户进程占用的cpu百分比
91.5%id,           空闲cpu的百分比
0.0%wa,            等待输入和输出的服务占用cpu百分比
0.0%hi,            硬中断请求服务占用的cpu百分比
0.0%si,            软中断请求服务占用的cpu百分比
0.0%st             虚拟时间百分比,即当有虚拟机时候,虚拟cpu等待实际cpu时间的百分比
*************/

top -d 5      #每五秒刷新一次
?或h          #显示交互模式帮助
P             #以cpu使用率排序
M             #以内存使用率排序
N             #以pid排序
q             #退出

pstree

pstree -p   #显示进程的pid
pstree -u   #显示进程的所属用户

kill

kill -l           #查看可用的进程信号
kill -1 进程id     #相当于restart
kill -2 进程id     #相当于ctrl+c
kill -9 进程id     #强制立即结束程序运行
kill -15 进程id    #默认的
kill -19 进程id    #相当于ctrl+z
kill -9 -t tty1   #踢掉本地终端tty1的用户

&、jobs、fg

tar -zcf etc.tar.gz /etc &     #放入后台运行
top &                          #会暂停,因为top是前台展示的交互命令,放入后台就没有意义就暂停了。
jobs -l                        #显示后台的工作,-l参数显示pid
fg %工作号                      #%可以省略

vmstat、dmesg、free、uptime、uname、lsa_release、crontab

vmstat 1 3          #监控系统资源,刷新延时为1秒 刷新3次
dmesg | grep CPU    #开机时内核检测信息
free [-b|-m|-k|g]   #以字节为单位显示,byte,KB,MB,GB
cat /proc/cpuinfo   #查看cpuinfo
uptime              #查看系统启动时间和平均负载,top,w命令也能看到这个数据

uname -a            #查看系统所有有关信息
uname -r            #查看内核版本
uname -s            #查看内核名称
file /bin/ls        #查看系统多少位
lsb_release -a      #查看发行版本


crontab             #如果有百分号要有转义符,不是立即执行,判断系统是否繁忙,不繁忙则执行。crond

lsof

lsof -c 字符串    #列出以字符串开头的进程打开的文件
lsof -u 用户名    #列出某个用户的进程打开的文件
lsof -p 进程id    #列出某个pid进程打开的文件
2009-07-27 13:11:00 wupangzi 阅读数 1291
  • Linux系统编程、网络编程》第6章 信号

    课程内容: 学习本章的意义、Linux下都有哪些信号、signal函数、子进程对父进程信号的集成情况、kill、raise、alarm、pause、abort函数、信号休眠函数的唤醒、信号的发送、接收和处理的过程、如何调用API修改信号的屏蔽字。

    328 人正在学习 去看看 张先凤
    最近看到有人写了文章说对unix下的signal可以自定义信号,抱着怀疑的态度,进行了测试,结果是不可以自定义signal(在不重编译系统源码的基础上)。仔细分析一下,内核如果对数据进行控制,那么校验判断之下一定是不过的。这在测试的时候使用kill,raise的时候可以得到判断,返回值都是错误的,因而是没有发送出去,自然就无法收到。查看linux的sys_signal源码确实有范围判断,在里面同时将SIGKILL和SIGSTOP这2个信号进行排除,因为不允许用户进行捕获。至于,自定义的信号值在调用signal的时候是否成功,应该要依旧于系统内核的实现方式来判断,在linux下应该是失败的。
    其实在unix中有2个信号提供给用户使用,是SIGUSR1,SIGUSR2。可以使用这2个进行一定的操作。
2011-01-11 12:04:00 bly1126 阅读数 4060
  • Linux系统编程、网络编程》第6章 信号

    课程内容: 学习本章的意义、Linux下都有哪些信号、signal函数、子进程对父进程信号的集成情况、kill、raise、alarm、pause、abort函数、信号休眠函数的唤醒、信号的发送、接收和处理的过程、如何调用API修改信号的屏蔽字。

    328 人正在学习 去看看 张先凤

先装php5.3.5

'./configure' '--prefix=/home/php535' '--enable-xml' '--enable-fpm' '--with-curl'

这里最重要的是--enable-fpm。fastcgi已经在php5.3.5的core中了,不必再configure时--enable-fastcgi了。老版本的需要加,比如5.2

make && make install

这都是顺利的,然后就不知怎么启,误以为phppath/sbin/php-fpm就行了,可是一直起不来,报错:failed to post process the configuration。baidu了一个周末,还是不明白。觉得我已在etc下写了php-fpm.conf了呀,又以phppath/sbin/php-fpm -y etc/php-fpm.conf起,依然起不来。想了N久,觉得它这里指的conf文件应该php.ini,于是从源码中把php.ini找到,拷了过来,依然起不来.......

在php社区中逛时,发现有人提到的init.d.php-fpm。于是从源码中把它拷过来, phppath/init.d.php-fpm start。就起来了。。。

这都哪儿跟哪儿啊。

 

nginx其实已装了,只是光能解析html,于是改了nginx.conf文件

        location ~ /.php$ {
        #    root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi.conf;
        }

把这段加上,写了个index.php,果然可以解析了。。。。

 ps:init.d.php-fpm start这个如果重新运行了时,一定nginx也要重新启一下,否则,虽然php-fpm与nginx通信的端口起来了,但nginx所listen的端口仍然没有起来


其实,nginx支持平滑重启,不必停止服务的,这也是它广受好评的原因。具体的命令就是kill -HUP `cat yourpath/nginx/logs/nginx.pid`

但这个重启,并不好,在nginx.conf有问题时(也许是新加了模块时),并未真正重启,还是用nginx/sbin/nginx -c nginx.conf吧。当然停止用nginx/sbin/nginx  -s stop

还是觉得,只是上网找别人写的例子,不够。尤其有的人写的太短,根本没说明白怎么样一步一步地修改,安装,有些人写的太长,扯来扯去的,找不出骨架。

 

我写的也不好。。。。所以写个技术文档,不是个容易的活。。。

没有更多推荐了,返回首页