作者回复: 是的,这个演示为了方便初学linux的同学理解,所以用了复制。
在生产环境中,应该把cp命令改为mv命令,因为linux文件系统中,改名并不会影响已经打开文件的写入操作,内核inode不变,这样就不会出现丢日志了。
谢谢你的提醒,视频最后应该提一下这个事的。
作者回复: 先回答第1个问题:用lsof -p 进程号,可以看到进程打开的句柄,也包括监听的端口。用netstat命令也可以看到一些端口被哪些进程打开。或者直接在/proc目录中找进程的相关信息也可以。
第2个问题:可以用kill -QUIT把老master杀掉。
第3个问题:直接用kill -USR1来执行reload,不要用-s reload,这样还是老的nginx worker起来
作者回复: 谢谢!
作者回复: 是的,这个演示为了方便初学linux的同学理解,所以用了复制。
在生产环境中,应该把cp命令改为mv命令,因为linux文件系统中,改名并不会影响已经打开文件的写入操作,内核inode不变,这样就不会出现丢日志了。
谢谢你的提醒,视频最后应该提一下这个事的。
作者回复: USR1是切割日志的,对应reopen命令。而HUP是对应reload命令,它会在没有worker进程时启动worker进程。所以,回退应该用HUP信号。
作者回复: 旧nginx进程仍然在LISTEN,只是不会去处理这个socket,因为没有把它加到epoll中。master进程打开监听端口,但不处理,由worker进程处理。另外,旧master是新master的父进程,所以新master才能共享打开的监听端口。
作者回复: :-)
作者回复: openresty只是nginx上包了新的nginx模块,只需要忽略openresty/这一层目录,其他照着nginx的方式使用就可以了。
第六部分会介绍openresty,第四部分在单机上搭环境验证时,会同时搭建openresty和nginx作为反向代理
作者回复: 25课详细介绍了这一流程,建议先读完这一课。
reload实际上是向master进程发送HUP信号要求重启worker进程,如果master进程下没有worker进程,则相当于按nginx.conf启动worker进程,因此向老master发送HUP(这一课不知道是不是有口误,请以PDF为准,USR1与热部署无关)则相当于把老版本的Nginx恢复处理请求了。
如果执行-s reload,实际是去读取新master进程的id,向新master进程发送HUP信号了。执行nginx -s时,此时的nginx进程只是个发信号的工具而已,与新老版本关系不大。
作者回复: 对lsof的解读,要看LISTEN字段!当worker进程名变为nginx: worker process is shutting down时,lsof -p 6602 | grep LISTEN时可以看到没有在监听端口
作者回复: 打开DEBUG日志(第六部分课程里有介绍如何分析DEBUG级别日志),以此分析原因
作者回复: 可以
作者回复: nginx官方没有提供logrotate,因为我们mv后直接reopen或者发送USR1信号就可以了。由nginx来做reopen更简单纯粹,因为nginx进程收到信号后,会把cycle里保存的所有打开的文件句柄,关闭掉再打开即可,就会生成新的日志文件。
作者回复: 比如,nginx非正常退出时,就会出现这个问题。原因是,nginx.pid里存放的还是之前进程的pid,但实际上进程已经不在,这个时候,reload是不能执行的,一定要执行,就会向错误或者不存在的进程发送信号
作者回复: 运行时提示没有动态模块,可以参见第41课。
如果是某些指令没有编译进nginx,需要configure后重编译
作者回复: 通常,是新版本的nginx与现在的nginx.conf不匹配导致的,你看下error.log,上面有详细的信息
作者回复: 指向旧的目录
作者回复: 先要查看为何停止nginx会失败。你可以把打开debug日志看下,关于debug日志如何阅读可以看下第143课