nginx重启后,反向代办失利之问题排查纪录_腾讯云双十一,阿里云

  • nginx重启后,反向代办失利之问题排查纪录_腾讯云双十一,阿里云已关闭评论
  • 209 人浏览
  • A+
所属分类:教程分享 首页

问题与排查历程

当地开发环境的效劳器,布置了nginx,nginx上对静态的web前端页面进行了http 80端口代办;然后呢,由于一些缘由,效劳器重启了,重启效劳器后,我去把nginx启动起来,然则nginx怎样也代办不了80端口,问题以下:

  1. 浏览器接见没相应,当地telnet效劳器的80端口是通的,运用wireshark抓包,历程以下:

    nginx重启后,反向代办失利之问题排查纪录_腾讯云双十一,阿里云

    包3-包7,tcp 三次握手;

    包8,本机给开发效劳器发了http要求;

    包9,本机重传;

    包10,效劳器返回ack,确认收到要求,然则依旧没有要求返回。

    后续一向没有要求返回

  2. 效劳器端,将nginx.conf进行了精简,精简后,重要设置以下:

    server {
            listen       80;
            server_name  localhost;
            gzip on;
            gzip_http_version 1.1;
            gzip_comp_level 3;
            gzip_types text/plain application/json application/javascript text/css  image/jpeg image/gif image/png application/zip;
    
            access_log  logs/host.access.log;
    
            #这里对web前端静态页面做了代办,途径为/police3-web/scm
            location / {
                root   /police3-web/scm;
                try_files $uri index.html /index.html;
                if ($request_filename ~* \.(gif|jpg|jpeg|png|css|js|ico|eot|otf|fon|font|ttf|ttc|woff|woff2)$) {
                  expires   7d;
                }
            }
            location ^~ /scm {
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header Host $host;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_pass http://localhost:9080;
    
            }
    
            location ~/group([0-9])/M([0-9])([0-9]) {
                    add_header Access-Control-Allow-Origin *;
                    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
                    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
                    #ngx_fastdfs_module;//由于疑心和fastdfs有关联,特地解释了
            }
    
        }
    
  3. 重启nginx后,视察logs/error.log:

    2019/12/06 08:56:53 [alert] 10588#0: worker process 10802 exited on signal 11 (core dumped)
    2019/12/06 08:56:53 [alert] 10588#0: worker process 10802 exited on signal 11 (core dumped)
    2019/12/06 08:56:53 [alert] 10588#0: worker process 10802 exited on signal 11 (core dumped)
    2019/12/06 08:56:53 [notice] 10588#0: start worker process 10806
    2019/12/06 08:56:53 [notice] 10588#0: start worker process 10806
    ngx_http_fastdfs_process_init pid=10806
    2019/12/06 08:56:56 [notice] 10588#0: signal 17 (SIGCHLD) received from 10806
    2019/12/06 08:56:56 [notice] 10588#0: signal 17 (SIGCHLD) received from 10806
    2019/12/06 08:56:56 [alert] 10588#0: worker process 10806 exited on signal 11 (core dumped)
    2019/12/06 08:56:56 [alert] 10588#0: worker process 10806 exited on signal 11 (core dumped)
    2019/12/06 08:56:56 [alert] 10588#0: worker process 10806 exited on signal 11 (core dumped)
    2019/12/06 08:56:56 [notice] 10588#0: start worker process 10808
    2019/12/06 08:56:56 [notice] 10588#0: start worker process 10808
    ngx_http_fastdfs_process_init pid=10808
    2019/12/06 08:56:59 [notice] 10588#0: signal 17 (SIGCHLD) received from 10808
    2019/12/06 08:56:59 [notice] 10588#0: signal 17 (SIGCHLD) received from 10808
    2019/12/06 08:56:59 [alert] 10588#0: worker process 10808 exited on signal 11 (core dumped)
    2019/12/06 08:56:59 [alert] 10588#0: worker process 10808 exited on signal 11 (core dumped)
    2019/12/06 08:56:59 [alert] 10588#0: worker process 10808 exited on signal 11 (core dumped)
    2019/12/06 08:56:59 [notice] 10588#0: start worker process 10812
    2019/12/06 08:56:59 [notice] 10588#0: start worker process 10812

    差不多就是循环往复地打这些日记,然后我就去百度了一下,查到了这篇:

    https://blog.csdn.net/hexuan1/article/details/45222867

    内里提到了dmesg敕令,我这边也执行了一下,输出以下:

    [55522.992453] nginx[10844]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55526.018405] nginx[10851]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55529.043590] nginx[10853]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55532.070932] nginx[10855]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55535.097444] nginx[10859]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55538.122466] nginx[10861]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55541.148914] nginx[10871]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55544.201955] nginx[10914]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55547.229135] nginx[10921]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55550.254445] nginx[10923]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55553.279543] nginx[10928]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55556.305874] nginx[10932]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55559.331128] nginx[10936]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55562.356655] nginx[10938]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55565.408411] nginx[10943]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55568.434908] nginx[10948]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]
    [55571.459719] nginx[10950]: segfault at 4 ip 00007f23d017ff84 sp 00007ffdf82783e0 error 4 in libfdfsclient.so[7f23d0179000+18000]

    我注意到,这内里提到了:libfdfsclient.so,由于我们的nginx对fastdfs进行了代办(这块同事弄的,临时没问详细机制,搜了一下,也许以下:https://blog.csdn.net/qq_34301871/article/details/80060235

    我就想,之前同事彷佛和我说,要把fastdfs重新启动起来,我一想,大概效劳器重启后,fastdfs没启动致使的。

    然后执行了一下敕令,重启了fastdfs相干效劳:

    /etc/init.d/fdfs_trackerd start
    /etc/init.d/fdfs_storaged start

    然后再视察nginx的error.log,竟然就没有一向打印上面的毛病日记了:

    2019/12/06 08:58:21 [notice] 10588#0: signal 17 (SIGCHLD) received from 10950
    2019/12/06 08:58:21 [notice] 10588#0: signal 17 (SIGCHLD) received from 10950
    2019/12/06 08:58:21 [alert] 10588#0: worker process 10950 exited on signal 11 (core dumped)
    2019/12/06 08:58:21 [alert] 10588#0: worker process 10950 exited on signal 11 (core dumped)
    2019/12/06 08:58:21 [alert] 10588#0: worker process 10950 exited on signal 11 (core dumped)
    2019/12/06 08:58:21 [notice] 10588#0: start worker process 10954
    2019/12/06 08:58:21 [notice] 10588#0: start worker process 10954
    ngx_http_fastdfs_process_init pid=10954
      ##重启fastdfs效劳后,这里日记就稳固在下面这一行,没有一向打印毛病了:
    [2019-12-06 08:58:23] INFO - fastdfs apache / nginx module v1.21, response_mode=proxy, base_path=/tmp, url_have_group_name=1, group_name=group1, storage_server_port=23000, path_count=1, store_path0=/home/fastdfs/storage, connect_timeout=2, network_timeout=30, tracker_server_count=1, if_alias_prefix=, local_host_ip_count=3, anti_steal_token=0, token_ttl=0s, anti_steal_secret_key length=0, token_check_fail content_type=, token_check_fail buff length=0, load_fdfs_parameters_from_tracker=1, storage_sync_file_max_delay=86400s, use_storage_id=0, storage server id/ip count=0 / 0, flv_support=1, flv_extension=flv
    2019/12/06 09:00:32 [info] 10954#0: *2 client timed out (110: Connection timed out) while waiting for request, client: 10.15.4.46, server: 0.0.0.0:80
  4. 那,毛病排查就到这里了。略坑略坑。

参考

dmesg敕令:

https://www.runoob.com/linux/linux-comm-dmesg.html

https://www.cnblogs.com/zhaoxuguang/p/7810651.html

腾讯云双十一活动