han4235

恩， 我们只是讨论下这个问题， 这个问题其实蛮严重的， 按照nginx原生的设计原理， reload是重新开启进程，原有的进程之上的链接直至全部断开才会停用， 并且原有的进程不会再继续监听端口， 新的链接请求会被分配到新的进程，这样造成的后果，原来的推流一直在， 但是客户端再去拉流，其实是拉不到流的。

我倒是有个思路， 类似于rtmp_auto_push，服务reload之后， 老进程里面保留的推流， 主动往新进程推送， 这样保证新链接进来之后， 能够从新的进程里拉到流， 同时也不破坏nginx原有的机制， 老进程的链接都正常消亡之后， 再推出，流自然断开之后， 就顺利被新进程接管了。

已经修改好了， 其实很简单，在ngx_rtmp_auto_push_reconnect这个接口里面稍微修改一下

将定时器开启， 推流进程自动会检测是否有新进程， 然后再把流推过去就好了， 这样新老进程都有流， 当推流结束的时候， 老进程就会自然消亡。

谢谢你的解释， 现在都是多核时代了， 甚至到了64cpu的，也就是说pull拉流回源多则32路回源，再加上分布式部署N台机器的话，无形中对中心机产生了很大的不必要的链接，当然nginx的机制跟srs不一样，srs的做法是单进程多线程所以一个source就可以解决问题。我记得nginx rtmp有个补丁， 这个补丁是将nginx worker每个都绑定不同的端口，端口之间进行合并压缩， 但这个方式我想似乎牺牲了 nginx多进程的优势。

我现在的想法是这样的， 这里有个补丁： https://rarut.wordpress.com/2013/06/18/multi-worker-statistics-and-control-with-nginx-per-worker-listener-patch/ 将worker绑定不同的端口，前端做对流进行hash转到固定的worker里面去， 这样的方式是我目前觉得算是一个比较合理的方案。

It should be the failure of the backend upstream to release the file descriptor that caused the assertion to fail. `TRANS_BY_GPT3`