停止操作是通过向nginx进程发送信号（什么是信号请参阅linux文 章）来进行的
步骤1：查询nginx主进程号
ps -ef | grep nginx
在进程列表里 面找master进程，它的编号就是主进程号了。
步骤2：发送信号
从容停止Nginx：
kill -QUIT 主进程号
快速停止Nginx：
kill -TERM 主进程号
强制停止Nginx：
pkill -9 nginx
另外， 若在nginx.conf配置了pid文件存放路径则该文件存放的就是Nginx主进程号，如果没指定则放在nginx的logs目录下。有了pid文 件，我们就不用先查询Nginx的主进程号，而直接向Nginx发送信号了，命令如下：
kill -信号类型 '/usr/nginx/logs/nginx.pid'
平滑重启
如果更改了配置就要重启Nginx，要先关闭Nginx再打开？不是的，可以向Nginx 发送信号，平滑重启。
平滑重启命令：
kill -HUP 住进称号或进程号文件路径
或者使用
/usr/nginx/sbin/nginx -s reload
nginx -t -c /usr/nginx/conf/nginx.conf
或者
/usr/nginx/sbin/nginx -t平滑升级
如果服务器正在运行的Nginx要进行升级、添加或删除模块时，我们需 要停掉服务器并做相应修改，这样服务器就要在一段时间内停止服务，Nginx可以在不停机的情况下进行各种升级动作而不影响服务器运行。
步骤1：
如 果升级Nginx程序，先用新程序替换旧程序文件，编译安装的话新程序直接编译到Nginx安装目录中。
步 骤2：执行命令
kill -USR2 旧版程序的主进程号或进程文件名
此时旧的Nginx主进程将会把自己的进程文件改名为.oldbin，然后执行新版 Nginx。新旧Nginx会同市运行，共同处理请求。
这时要逐步停止旧版 Nginx，输入命令：
kill -WINCH 旧版主进程号
慢慢旧的工作进程就都会随着任务执行完毕而退出，新版的Nginx的工作进程会逐渐取代旧版 工作进程。
此 时，我们可以决定使用新版还是恢复到旧版。
不重载配置启动新/旧工作进程
kill -HUP 旧/新版主进程号
从容关闭旧/新进程
kill -QUIT 旧/新主进程号
如果此时报错，提示还有进程没有结束就用下面命令先关闭旧/新工作进程，再关闭主进程号：
kill -TERM 旧/新工作进程号
这样下来，如果要恢复到旧版本，只需要上面的几个步 骤都是操作新版主进程号，如果要用新版本就上面的几个步骤都操作旧版主进程号就行了。
上面就是Nginx的一些基本的操作，希望以后Nginx能有更好的方法来处理这些操作， 最好是Nginx的命令而不是向Nginx进程发送系统信号。
在使用的阿里云服务器上，进程性的 nginx -s stop后再次启动nginx -s reload ,总是会报错误nginx: [error] open() "/alidata/server/nginx/logs/nginx.pid" failed (2: No such file or directory)，这应该是因为把nginx进程杀死后pid丢失了，下一次再开启nginx -s reload时无法启动，重装可以解决这个问题，但是太麻烦了。
一开始百度解决该问题。只是找到几个求助答案。没有实际有效的方法，于是用google开始搜索，虽然英语比较恶心，但一般，英文网站上总会有解决方法这一次也不另外。
issued a nginx -s stop and after that I got this error when trying to reload it.
[error]: invalid PID number "" in "/var/run/nginx.pid"
That /var/run/nginx/pid file is empty atm.
What do I need to do to fix it?
nginx -s reload is only used to tell a running nginx process to reload its config. After a stop, you don't have a running nginx process to send a signal to. Just run nginx (possibly with a -c /path/to/config/file)
于是我用了这方法，也就是nginx -c /path/to/config/file) //在我机器上是这样的/alidata/server/nginx/sbin/nginx -c /alidata/server/nginx/conf/nginx.conf
Win7实现快速启动栏并实现靠左边的终极操作方法（已解决）！
1、右击任务栏空白处（别点图标） ----- 工具栏 ----- 新建工具栏 ----- %userprofile%\AppData\Roaming\Microsoft\Internet
Explorer\Quick Launch
2、 右键Quick Launch，把显示文本和显示标题的勾去掉。
3、右击任务栏空白处（别点图标）选属性，把锁定任务栏的勾去掉，在【任务栏按钮】中选择【始终合并，隐藏标签】（这太关键了！）
4、呵！呵！可以拖动了吧！
前文链接：《深入理解Nginx》阅读与实践（一）：Nginx安装配置与HelloWorld
HelloWorld的完成意味着已经踏入了nginx的大门，虽然很振奋人心，但在编写中仍有很多疑惑的存在：nginx.conf的配置项中各个参数是如何读入程序中的？ngx_command_t如何完成配置项的读入工作？名称相同的配置项的冲突如何解决？HelloWorld中的ngx_http_module_t何以称为模块的上下文？同时我在读第4章"配置项的使用"时又有成见：不就是各种琐碎的参数设置嘛，有什么好读的？（这个成见来自于UNP中某一章节套接字选项）不过经过仔细阅读并实践这部分内容之后，我发现完全八竿子打不着要点。其实这里的配置项的使用，是指将我们在nginx.conf中设置的配置项的参数传递到nginx程序的过程。同时，经过这一章，你将学到如何将一个“根据用户请求的URI返回HelloWorld的模块”变成一个“可以完成解析各种nginx配置项的模块”。
一、存放配置项的值的数据结构
先来看看文中介绍的保存配置参数的数据结构ngx_http_mytest_conf_t：
typedef struct {
ngx_str_t my_str;
ngx_int_t my_num;
ngx_flag_t my_flag;
size_t my_size;
ngx_array_t* my_str_array;
ngx_array_t* my_keyval;
off_t my_off;
ngx_msec_t my_msec;
time_t my_sec;
ngx_bufs_t my_bufs;
ngx_uint_t my_enum_seq;
ngx_uint_t my_bitmask;
ngx_uint_t my_access;
ngx_path_t* my_path;
} ngx_http_mytest_conf_t;
与原书提到的问题（为什么不用全局变量来存储）不同，我的问题是，既然想要统一用一个结构体存放各种各样的配置项如整数、标记（非0即1）、字符串、时间等等，为什么不用一个联合从而节省空间？带着疑问继续往下读才会发现：这里的数据结构是为了便于后面说明预设配置项解析方法而定义的，它能处理的配置项是下面这种形式：
name [ngx_str_t] [ngx_int_t] ... [ngx_path_t*] [[ngx_str_t][ngx_int_t]]
这种配置项的名称后面可以跟着14种参数以及在后文定义的myconfig的2个参数，这16个参数可以全部出现，也可以只出现其中之一。也即，它的功能并不是仅仅处理配置项名+单一参数的配置项，而是所有可能形式的配置项。这样复杂在所难免，如果实际使用的配置项是我们所能控制的有限几种，没有必要设计这么复杂，正如HelloWorld中mytest配置项后根本就没有值，只是设立了个遇到该配置项就启动mytest模块的函数而已，那时甚至没有必要设计这么一个保存配置项的值的结构。
二、对配置项的值的操作：读取与合并
回顾HelloWorld中的代表模块上下文的ngx_http_module_t结构，之前虽然提到它是模块的上下文，使得模块具有自己的特性，但当时把它的8个回调方法都设置成了NULL，也看不出什么名堂。这时《深入理解Nginx》对它做了个回顾并说明，我是这样理解的：所谓“上文”，就是做preconfiguration的工作、处理nginx.conf的配置项（将所有配置项读入、建立数据结构保存、各级同名配置项合并）；“下文”就是在处理完配置项后调用函数postconfiguration进行一些后续工作。
static ngx_http_module_t ngx_http_mytest_module_ctx =
{
NULL, /* preconfiguration */
ngx_http_mytest_post_conf, /* postconfiguration */
NULL, /* create main configuration */
NULL, /* init main configuration */
NULL, /* create server configuration */
NULL, /* merge server configuration */
ngx_http_mytest_create_loc_conf, /* create location configuration */
ngx_http_mytest_merge_loc_conf /* merge location configuration */
};
为了便于说明，这里只实现了create_loc_conf和merge_loc_conf，前者在nginx.conf中的每一个http{...}、server{...}、location{...}都会调用来为ngx_http_mytest_conf_t赋初值；后者用来合并create_loc_conf生成的所有ngx_http_mytest_conf_t的配置项。
除此以外，为了打印出读取的配置项的值，需要实现ngx_http_mytest_post_conf，在处理完配置项后调用。这样，模块的上下文便写好了。
关于create_loc_conf、create_srv_conf、create_main_conf的调用时机：
create_loc_conf是遇到每一个http{...}、server{...}、location{...}时；
create_srv_conf是遇到每一个server{...}、location{...}时；
create_main_conf只在遇到http{...}时。
这个细节可以参考原书。
关于merge_srv_conf的调用作用：合并main级别和server级别的配置项，请参考10.2.4。
这时就可以通过设定ngx_command_s来设定配置项的解析方式了，简单概括就是配置项的名称、它所能出现的位置、对值处理的回调方法也即解析方法、值存放于之前定义的数据结构的偏移量。这一系列解析方式构成了一个数组，用来解析所有可能出现的配置项的形式。这里原书说的比较详细，就不再重复。对应14种配置项的值的类型，书上讲了14种解析方式和针对自定义配置项的处理方法（对应的回调函数是ngx_conf_set_myconfig）。
这里不得不提一下ngx_conf_t类型。原书中多次出现在函数原型形参中但并未提及，我查了一些资料，它的定义如下：
struct ngx_conf_s {
char *name;
ngx_array_t *args;
ngx_cycle_t *cycle;
ngx_pool_t *pool;
ngx_pool_t *temp_pool;
ngx_conf_file_t *conf_file;
ngx_log_t *log;
void *ctx;
ngx_uint_t module_type;
ngx_uint_t cmd_type;
ngx_conf_handler_pt handler;
char *