精华内容
下载资源
问答
  • tomcat日志无输出意外停止问题分析

    千次阅读 2018-11-15 18:00:00
    节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory的整个过程: org.apache.coyote.AbstractProtocol pause Pausing ProtocolHandler...

    节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory的整个过程:

    org.apache.coyote.AbstractProtocol pause
    Pausing ProtocolHandler
    org.apache.catalina.core.StandardService stopInternal
    Stopping service Catalina
    org.apache.coyote.AbstractProtocol stop
    Stopping ProtocolHandler
    org.apache.coyote.AbstractProtocol destroy
    Destroying ProtocolHandler
    

    从上面日志来可以判断:

    1. tomcat不是通过脚本正常关闭(viaport: 即通过8005端口发送shutdown指令)
      因为正常关闭(viaport)的话会在 pause 之前有这样的一句warn日志:
        org.apache.catalina.core.StandardServer await
        A valid shutdown command was received via the shutdown port. Stopping the Server instance.
    

    然后才是 pause -> stop -> destory

    1. tomcat的shutdownhook被触发,执行了销毁逻辑

    而这又有两种情况,一是应用代码里有地方用System.exit来退出jvm,二是系统发的信号(kill -9除外,SIGKILL信号JVM不会有机会执行shutdownhook)

    先通过排查代码,应用方和中间件团队都排查了System.exit在这个应用中使用的可能。那就只剩下Signal的情况了;经过一番排查后,发现每次tomcat意外退出的时间与ssh会话结束的时间正好吻合。

    有了这个线索之后,银时同学立刻看了一下对方测试环境的脚本,简化后如下:

    $ cat test.sh
    #!/bin/bash
    cd /data/server/tomcat/bin/
    ./catalina.sh start
    tail -f /data/server/tomcat/logs/catalina.out
    

    tomcat启动为后,当前shell进程并没有退出,而是挂住在tail进程,往终端输出日志内容。这种情况下,如果用户直接关闭ssh终端的窗口(用鼠标或快捷键),则java进程也会退出。而如果先ctrl-c终止test.sh进程,然后再关闭ssh终端的话,则java进程不会退出。

    这是一个有趣的现象,catalina.sh start方式启动的tomcat会把java进程挂到init(进程id为1)的父进程下,已经与当前test.sh进程脱离了父子关系,也与ssh进程没有关系,为什么关闭ssh终端窗口会导致java进程退出?

    我们的推测是ssh窗口在关闭时,对当前交互的shell以及正在运行的test.sh等子进程发送某个退出的Signal,找了一台装有systemtap的机器来验证,所用的stap脚本是从涧泉同学那里copy的:

    function time_str: string () {
        return ctime(gettimeofday_s() + 8 * 60 * 60);
    }
    
    probe begin {
        printdln(" ", time_str(), "BEGIN");
    }
    
    probe end {
        printdln(" ", time_str(), "END");
    }
    
    probe signal.send {
        if (sig_name == "SIGHUP" || sig_name == "SIGQUIT" || 
            sig_name=="SIGINT" || sig_name=="SIGKILL" || sig_name=="SIGABRT") {
            printd(" ", time_str(), sig_name, "[", uid(), pid(), cmdline_str(), 
                    "] -> [", task_uid(task), sig_pid, pid_name, "], ");
            task = pid2task(pid());
            while (task_pid(task) > 0) {
                printd(" ", "[", task_uid(task), task_pid(task), task_execname(task), "]");
                task = task_parent(task);
            }
            println("");
        }
    }
    

    模拟时的进程层级(pstree)大致如下,tomcat启动后java进程已经脱离test.sh,挂在init下:

    |-sshd(1622)-+-sshd(11681)---sshd(11699)---bash(11700)---test.sh(13285)---tail(13299)
    

    经过内核组伯俞的协助,我们发现
    a) 用 ctrl-c 终止当前test.sh进程时,系统events进程向 java 和 tail 两个进程发送了SIGINT 信号

    SIGINT [ 0 11  ] -> [ 0 20629 tail ] 
    SIGINT [ 0 11  ] -> [ 0 20628 java ] 
    SIGINT [ 0 11  ] -> [ 0 20615 test.sh ] 
    

    注pid 11是events进程

    b) 关闭ssh终端窗口时,sshd向下游进程发送SIGHUP, 为何java进程也会收到?

    SIGHUP [ 0 11681 sshd: hongjiang.wanghj [priv] ] -> [ 57316 11700 bash ] 
    SIGHUP [ 57316 11700 -bash ] -> [ 57316 11700 bash ]
    SIGHUP [ 57316 11700 ] -> [ 0 13299 tail ] 
    SIGHUP [ 57316 11700 ] -> [ 0 13298 java ] 
    SIGHUP [ 57316 11700 ] -> [ 0 13285 test.sh ] 
    

    不过伯俞很忙没有继续协助分析这个问题(他给出了一些猜测,但后来证明并不是那样)。

    确定了是由signal引起的之后,我的疑惑变成了:

    1. 为什么SIGINT (kill -2)不会让tomcat进程退出?
    2. 为什么SIGHUP (kill -1)会让tomcat进程退出?

    我第一反应可能是jvm在某些参数下(或因为某些jni)对os的信号处理会不同,看了一下应用的jvm参数,没有看出问题,也排除了tomcat使用apr/tcnative的情况。

    我们看一下默认情况下,jvm进程对SIGINT和SIGHUP是怎么处理的,用scala的repl模拟一下:

    scala> Runtime.getRuntime().addShutdownHook(
                new Thread() { override def run() { println("ok") } })
    

    对这个java进程分别用kill -2和kill -1发现都会导致jvm进程退出,并且也触发shutdownhook。这也符合oracle对hotspot虚拟机处理Signal的说明,参考这里,SIGTERM,SIGINT,SIGHUP三种信号都会触发shutdownhook

    看来并不是jvm的事,继续猜测是否与进程的状态有关?catalina.sh脚本里并没有使用start-stop-daemon之类的方式启动java进程,start参数的执行方式简化后脚本相当于:

    eval '"/pathofjdk/bin/java"' 'params' org.apache.catalina.startup.Bootstrap start '&'
    

    就是简单的把java放到后台执行。当catalina.sh自身进程退出后,java进程的ppid变成了1

    花了很多的时间猜测可能是OS层面的原因,后来发现并没有关系。春节后回来让少明和涧泉也一起分析这个问题,因为他们有c的背景,对系统底层知道的多一些,用了大半天时间,不断猜测和验证,最后确认了是Shell的原因。
    SIGINT (kill -2)不会让后台java进程退出的原因

    为了简便,我们用sleep来模拟进程,当我们在交互模式下:

    $ sleep 1000 & 
    
    $ ps -opid,pgid,ppid,stat,cmd -C sleep
      PID  PGID  PPID STAT CMD
    9897  9897  9813 S    sleep 1000   
    

    注意,进程sleep 1000的pid与pgid(进程组)是相同的,这时我们用kill -2是可以杀掉sleep 1000进程的。

    现在我们把sleep进程放到一个脚本里后台执行:

    $ cat a.sh
    #!/bin/sh
    sleep 4400 &
    echo "shell exit"
    

    运行a.sh脚本之后,sleep 4400进程的pid与pgid是不同的,pgid是其父进程的id,即已经退出了的a.sh进程

    $ ps -opid,pgid,ppid,comm -p 63376
      PID  PGID  PPID COMM
    63376 63375     1 sleep
    

    这时我们用kill -2是杀不掉sleep 4400进程的。

    到了这一步,已经非常接近原因了,一定是shell对后台进程signal_handler做了什么手脚。少明实现了一个自定handler的命令看看是否对kill -2有效:

    #include <stdio.h>
    #include <signal.h>
    #include <stdlib.h>
    
    void my_handler(int sig) {
        printf("handler aaa\n");
        exit(0);
    }
    
    int main() {
        signal(SIGINT, my_handler);
        for(;;) { }
        return 0;
    }
    

    我们把编译后的a.out命令在脚本里以后台方式运行:

    $ cat a.sh
    #!/bin/sh
    /tmp/a.out &
    

    这次再尝试用kill -2去杀a.out进程,是可以的。这说明shell对signal_handler做手脚是在执行用户逻辑之前,也就是脚本在fork出子进程的时候就设置了。按照这个线索我们google后了解到: shell在非交互模式下对后台进程处理SIGINT信号时设置的是IGNORE。
    交互模式与非交互模式对作业控制(job control)默认方式不同

    为什么在交互模式下shell不会对后台进程处理SIGINT信号设置为忽略,而非交互模式下会设置为忽略呢?还是比较好理解的,举例来说,我们先某个前台进程运行时间太长,可以ctrl-z中止一下,然后通过bg %n把这个进程放入后台,同样也可以把一个cmd &方式启动的后台进程,通过fg %n放回前台,然后在ctrl-c停止它,当然不能忽略SIGINT。

    为何交互模式下的后台进程会设置一个自己的进程组ID呢?因为默认如果采用父进程的进程组ID,父进程会把收到的键盘事件比如ctrl-c之类的SIGINT传播给进程组中的每个成员,假设后台进程也是父进程组的成员,因为作业控制的需要不能忽略SIGINT,你在终端随意ctrl-c就可能导致所有的后台进程退出,显然这样是不合理的;所以为了避免这种干扰后台进程设置为自己的pgid。

    而非交互模式下,通常是不需要作业控制的,所以作业控制在非交互模式下默认也是关闭的(当然也可以在脚本里通过选项set -m打开作业控制选项)。不开启作业控制的话,脚本里的后台进程可以通过设置忽略SIGINT信号来避免父进程对组中成员的传播,因为对它来说这个信号已经没有意义。

    回到tomcat的例子,catalina.sh脚本通过start参数启动的时候,就是以非交互方式后台启动,java进程也被shell设置了忽略SIGINT信号,因此在ctrl-c结束test.sh进程时,系统发送的SIGINT对java没有影响。
    SIGHUP (kill -1)让tomcat进程退出的原因

    在非交互模式下,shell对java进程设置了SIGINT,SIGQUIT信号设置了忽略,但并没有对SIGHUP信号设为忽略。再看一下当时的进程层级:

    |-sshd(1622)-+-sshd(11681)---sshd(11699)---bash(11700)---test.sh(13285)---tail(13299)
    

    sshd把SIGHUP传递给bash进程后,bash会把SIGHUP传递给它的子进程,并且对于其子进程test.sh,bash还会对test.sh的进程组里的成员都传播一遍SIGHUP。因为java后台进程从父进程catalina.sh(又是从其父进程test.sh)继承的pgid,所以java进程仍属于test.sh进程组里的成员,收到SIGHUP后退出。

    如果我们在test.sh里设置开启作业控制的话,就不会让java进程退出了

    #!/bin/bash
    set -m  
    cd /home/admin/tt/tomcat/bin/
    ./catalina.sh start
    tail -f /home/admin/tt/tomcat/logs/catalina.out
    

    此时java后台进程继承父进程catalina.sh的pgid,而catalina.sh不再使用test.sh的进程组,而是自己的pid作为pgid,catalina.sh进程在执行完退出后,java进程挂到了init下,java与test.sh进程就完全脱离关系了,bash也不会再向它发送信号。



    转自:https://blog.csdn.net/zhouyannian1988/article/details/53508689



    展开全文
  • Tomcat异常退出分析和解决办法

    千次阅读 2018-07-23 15:06:36
    一般情况引起tomcat异常退出的情况出现在下面几种情况: 1.并发用户数目过大,也会导致tomcat自动停止服务。 2.系统本身的网络负载平衡没有做好,导致tomcat自动停止服务; 3.程序迭代不合理也是一个原因; 4.数据库...

    一般情况引起tomcat异常退出的情况出现在下面几种情况: 1.并发用户数目过大,也会导致tomcat自动停止服务。 2.系统本身的网络负载平衡没有做好,导致tomcat自动停止服务; 3.程序迭代不合理也是一个原因; 4.数据库连接未关闭,导致资源损耗过重,会引起服务停止; 5.程序严重错误,也会引起tomcat停止服务! 通常情况下,如果冰法用户数目过大的话,可能会出现内存溢出现象,这时候需要针对tomcat的jvm内存配置进行修改,通常修改就是在catalina.bat中添加: set CATALINA_OPTS=-Xms128M -Xmx256M set JAVA_OPTS=-Xms128M -Xmx256M 或者把%CATALINA_OPTS%和%JAVA_OPTS%代替为-Xms128M -Xmx256M 具体数字需要根据具体情况而定。 还有一种情况就是通过优化程序代码完成内存的合理使用,这块内容需要找到程序中消耗内存的地方,减少循环之类的问题。 另外一种情况就是连接未关闭的问题,这个问题也是经常出现的,这块内容需要特别注意,或者引入连接池来做此事情,但是连接池设置的大小也需要特殊情况特殊处理,如果处理不好也会出现连接数过小访问出错的问题。 还有一种情况tomcat会异常退出,可以参见此博客http://ifeve.com/why-kill-2-cannot-stop-tomcat/,这里面提到的问题也是挺有意思,注意sshd关闭引起tomcat关闭问题。 还有一种情况是tomcat配置负载问题导致,这里可以参照http://www.cnblogs.com/shiyangxt/archive/2009/02/26/1398902.html 博客进行配置。 当然,经常使用tomcat的可能会遇到tomcat启动一闪而停的现象,这里可能是因为jdk环境变量配置问题,出现此问题可以先检查jdk环境是否配置好。 tomcat异常退出问题有很多种,需要进行严格的分析,如果后面再有遇到其他种类的异常退出,在及时更新。

    展开全文
  • Tomcat 异常关闭排查

    2018-07-04 12:38:00
    tomcat conf/server.xml https://blog.csdn.net/qq_30121245/article/details/52861935 pattern分析 %a 这是记录访问者的IP,在日志里是127.0.0.1 %A 这是记录本地服务器的IP,在日志里是192.168.254.108 %...

    N次请求

    tomcat conf/server.xml

    https://blog.csdn.net/qq_30121245/article/details/52861935

    pattern分析 

    %a   这是记录访问者的IP,在日志里是127.0.0.1
    %A   这是记录本地服务器的IP,在日志里是192.168.254.108
    %b   发送信息的字节数,不包括http头,如果字节数为0的话,显示为-
    %B   发送信息的字节数,不包括http头。
    %h   服务器的名称。如果resolveHosts为false的话,这里就是IP地址了,例如我的日志里是10.217.14.16
    %H   访问者的协议,这里是HTTP/1.0
    %l   官方解释:Remote logical username from identd (可能这样翻译:记录浏览者进行身份验证时提供的名字)(always returns '-')
    %m   访问的方式,是GET还是POST
    %p   本地接收访问的端口 
    %q   比如你访问的是aaa.jsp?bbb=ccc,那么这里就显示?bbb=ccc,就是querystring的意思
    %r   First line of the request (method and request URI) 请求的方法和URL
    %s   http的响应状态码 
    %S   用户的session ID,这个session ID大家可以另外查一下详细的解释,反正每次都会生成不同的session ID
    %t   请求时间
    %u   得到了验证的访问者,否则就是"-"
    %U   访问的URL地址,我这里是/rightmainima/leftbott4.swf
    %v   服务器名称,可能就是你url里面写的那个吧,我这里是localhost
    %D   Time taken to process the request,in millis,请求消耗的时间,以毫秒记
    %T   Time taken to process the request,in seconds,请求消耗的时间,以秒记

     

     

     

    内存溢出

     /var/log/message查看

    Jul  3 21:35:01 VM_0_15_centos systemd: Starting Session 158959 of user root.
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff816a3d91>] dump_stack+0x19/0x1b
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff81185e3d>] ? oom_unkillable_task+0xcd/0x120
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff8118cd85>] __alloc_pages_nodemask+0x405/0x420
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff811d1108>] alloc_pages_current+0x98/0x110
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff81182917>] __page_cache_alloc+0x97/0xb0
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff81184eb0>] filemap_fault+0x170/0x410
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffffc01b8156>] ext4_filemap_fault+0x36/0x50 [ext4]
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff811ad162>] __do_fault+0x52/0xe0
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff811ad60b>] do_read_fault.isra.44+0x4b/0x130
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff811b1f11>] handle_mm_fault+0x691/0xfa0
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff816a84c7>] ? do_nanosleep+0xa7/0xf0
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff816affb4>] __do_page_fault+0x154/0x450
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff816b02e5>] do_page_fault+0x35/0x90
    Jul  3 21:35:30 VM_0_15_centos kernel: [<ffffffff816ac508>] page_fault+0x28/0x30
    Jul  3 21:35:30 VM_0_15_centos kernel: Mem-Info:
    Jul  3 21:35:30 VM_0_15_centos kernel: lowmem_reserve[]: 0 975 975 975
    Jul  3 21:35:30 VM_0_15_centos kernel: lowmem_reserve[]: 0 0 0 0
    Jul  3 21:35:30 VM_0_15_centos kernel: Node 0 DMA: 32*4kB (UE) 43*8kB (UE) 30*16kB (UEM) 20*32kB (UE) 9*64kB (UEM) 3*128kB (UEM) 4*256kB (UEM) 2*512kB (U) 0*1024kB 0*2048kB 0*4096kB = 4600kB
    Jul  3 21:35:30 VM_0_15_centos kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
    Jul  3 21:35:30 VM_0_15_centos kernel: 4854 total pagecache pages
    Jul  3 21:35:30 VM_0_15_centos kernel: 0 pages in swap cache
    Jul  3 21:35:30 VM_0_15_centos kernel: Swap cache stats: add 0, delete 0, find 0/0
    Jul  3 21:35:30 VM_0_15_centos kernel: Free swap  = 0kB
    Jul  3 21:35:30 VM_0_15_centos kernel: Total swap = 0kB
    Jul  3 21:35:30 VM_0_15_centos kernel: 262044 pages RAM
    Jul  3 21:35:30 VM_0_15_centos kernel: 0 pages HighMem/MovableOnly
    Jul  3 21:35:30 VM_0_15_centos kernel: 7972 pages reserved
    Jul  3 21:35:30 VM_0_15_centos kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
    Jul  3 21:35:30 VM_0_15_centos kernel: [  335]     0   335    19545      179      41        0             0 systemd-journal
    Jul  3 21:35:30 VM_0_15_centos kernel: [  356]     0   356    29712       84      27        0             0 lvmetad
    Jul  3 21:35:30 VM_0_15_centos kernel: [  362]     0   362    10955      132      23        0         -1000 systemd-udevd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  441]     0   441    13863      113      27        0         -1000 auditd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  473]     0   473     6084      151      16        0             0 systemd-logind
    Jul  3 21:35:30 VM_0_15_centos kernel: [  474]    81   474     6659      125      18        0          -900 dbus-daemon
    Jul  3 21:35:30 VM_0_15_centos kernel: [  475]     0   475     1085       35       7        0             0 acpid
    Jul  3 21:35:30 VM_0_15_centos kernel: [  476]   998   476     2133       36      10        0             0 lsmd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  478]   999   478   134053     2157      57        0             0 polkitd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  479]     0   479   178540      433     181        0             0 rsyslogd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  764]     0   764     6464       52      18        0             0 atd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  765]     0   765    31566      201      19        0             0 crond
    Jul  3 21:35:30 VM_0_15_centos kernel: [  818]     0   818    28343     3124      53        0             0 dhclient
    Jul  3 21:35:30 VM_0_15_centos kernel: [  885]     0   885   141129     2730      96        0             0 tuned
    Jul  3 21:35:30 VM_0_15_centos kernel: [  896]     0   896    27511       32       9        0             0 agetty
    Jul  3 21:35:30 VM_0_15_centos kernel: [  897]     0   897    27511       32      12        0             0 agetty
    Jul  3 21:35:30 VM_0_15_centos kernel: [  940]     0   940    26499      245      53        0         -1000 sshd
    Jul  3 21:35:30 VM_0_15_centos kernel: [  990]    38   990     7994      184      22        0             0 ntpd
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 1302]     0  1302    25171      108      19        0             0 YDLive
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 1369]     0  1369   376850     1656     145        0             0 YDService
    Jul  3 21:35:30 VM_0_15_centos kernel: [27523]    32 27523    16255      170      35        0             0 rpcbind
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6775]     0  6775    30927      730      62        0             0 nginx
    Jul  3 21:35:30 VM_0_15_centos kernel: [28373]   996 28373    31564      959      63        0             0 nginx
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 1970]     0  1970   579444    48524     153        0             0 java
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6071]     0  6071    39351     1670      31        0             0 barad_agent
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6078]     0  6078    45425     2002      43        0             0 barad_agent
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6079]     0  6079   152605     2716      48        0             0 barad_agent
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6397]     0  6397    24324      115      19        0             0 sgagent
    Jul  3 21:35:30 VM_0_15_centos kernel: [  914]     0   914   672195   131050     500        0             0 java
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6625]     0  6625    36396      379      72        0             0 sshd
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6626]    74  6626    26499      274      53        0             0 sshd
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6639]     0  6639    95428     2672      75        0             0 python
    Jul  3 21:35:30 VM_0_15_centos kernel: [ 6645]     0  6645    25943      410      50        0             0 sshd
    Jul  3 21:35:30 VM_0_15_centos kernel: Out of memory: Kill process 914 (java) score 502 or sacrifice child
    Jul  3 21:35:30 VM_0_15_centos kernel: Killed process 914 (java) total-vm:2688780kB, anon-rss:524200kB, file-rss:0kB, shmem-rss:0kB
    Jul  3 21:35:31 VM_0_15_centos systemd-logind: Removed session 151212.
    Jul  3 21:36:01 VM_0_15_centos systemd: Started Session 158960 of user root.

     

    转载于:https://www.cnblogs.com/eason-d/p/9262716.html

    展开全文
  • Tomcat异常退出

    2017-09-18 10:20:00
    tomcat正常运行期间,会出现这样的报错,于是在网上搜了一下,发现有前辈,已找到解决办法,碎不甚明白其中缘由,但先记下,日后深研究: 我的机器的报错内容: SEVERE: Error processing request java.lang....

    tomcat正常运行期间,会出现这样的报错,于是在网上搜了一下,发现有前辈,已找到解决办法,碎不甚明白其中缘由,但先记下,日后深研究:

    我的机器的报错内容:

    SEVERE: Error processing request
    java.lang.NullPointerException
            at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:355)
            at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:673)
            at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:646)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402)
            at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
            at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
            at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:745)

    前辈的解答内容:
    今天我在服务器上的tomcat也是出现了这么个问题,发现是tomcat底层报出来的一个空指针异常,说是CharChunk这个类的append方法,一时间摸不着头脑,最后看看CharChunk源码发现
    这里的s参数为null才报的错,

    之所以s为null,那是因为从这里调用的defaulthostname为null,也就是说host.isNull()这个方法
    返回值是true,当是HTTP/1.0的 request没有"Host" header才会导致host is null,而我们现在的tomcat基本上都是HTTP/1.1,所以这个请求是不寻常的,很诡异,不知道什么时候调用的,但是可以解决,需要在server.xml中的
    <Engine name="Catalina" defaultHost="localhost">
    标签下配置一个

    <Host name="localhost" >
    </Host>

    ,这样他的defaultHost的值才不会被忽略,defaulthostname才会有值,这样就解决了那个tomcat运行时不时的报一个NullPointerException。

    转载于:https://www.cnblogs.com/andyxq/p/7541796.html

    展开全文
  • ``` ... WARNING: Server seen down: /:27017 - java.io.IOException - message: couldn't connect to [/17017] bc:java.net.SocketTimeoutException: connect timed out ... ...WARNING: Server seen down: /:27017 - ...
  • 最近服务器tomcat和mysql经常死掉, 去查日志文件也没任何error log, 非常奇怪, 最后查出来,原来是linux系统的oom killer机制在内存不够用的时候把内存占用最大的进程杀掉了, 因为kill -9 pid 杀死进程时也是...
  • Tomcat异常停止

    千次阅读 2014-12-11 18:45:27
    2014-12-04 02:25:20(UTC)左右tomcat异常停止 当前内存使用如下: ops@vms-103:/var/log$ free -m  total used free shared buffers cached Mem: 7974 5349 2624 
  • 停止时会打印如下日志: 30-Jul-2018 13:23:56.786 INFO [Thread-8] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-10001"] 30-Jul-2018 13:23:56.839 INFO [Thread-8] org.apache....
  • 今天启动Tomcat启动不了,报以下错: org.apache.catalina.core.StandardContext startInternalSEVERE: Error listenerStartorg.apache.catalina.core.StandardContext startInternalSEVERE: Context [/******] ...
  • TOMCAT异常退出分析和解决方法

    万次阅读 2015-09-29 19:39:47
    最近遇到一个很诡异的问题,远程登录服务器,本来是想查看一下Tomcat的运行情况,结果用鼠标把窗体一拖,Tomcat居然自己关上了!就好像是自己按下了Ctrl+C一样!同事的电脑都没有出现这种情况,后来换了鼠标也不行...
  • window server 2012 tomcat7.0安装版概况:在项目开发中,使用java的JNative调用window下的dll文件,在项目上线的初期试点,业务量不大的时候一切正常,但是随着使用的用户量变大,tomcat的服务会不定期的停止,...
  • docker安装tomcat下的日志查看

    千次阅读 2020-04-04 00:12:26
    目录描述进行原因扩展解决参考 ...一般来说,出现问题,排查日志能解决大部分情况。可是docker进入运行中的tomcat,发现logs目录下并没有网上说的/usr/local/tocmat/logs/catalina.out文件,为了再确认下,在to...
  • Tomcat异常处理

    千次阅读 2015-07-31 21:17:48
    初次接触tomcat各种问题层出不穷,就我最近遇到的问题做一个总结。 PS:我安装的JDK是1.8.0_51 tomcat版本:apache-tomcat-7.0.63 免安装版本 1.闪退问题 在cmd命令中在tomcat的bin目录下输入startup.bat D:\...
  • Tomcat的启动与停止

    千次阅读 2019-06-01 10:25:28
    版权声明:本文为博主...Tomcat 的启动和停止脚本存在于bin 目录下面,这里存放了tomcat 启动和停止的众多相关脚本。 其中,各脚本用途 catalina : tomcat 的主要脚本,它会执行Java命令以调用tomcat的启动与停...
  • 没有hs_err_xxx.log文件生成【基本可以推论JVM没有出现严重的crash异常】 问题分析 1)通过catalina.log 看出tomcat出现了非正常关闭操作下的停机;如果是正常停机会在输出图1的日志前输出如图2所示的内容 ...
  • 定时删除tomcat日志

    2019-08-09 16:33:12
    linux上的tomcat日志如果清理不及时,会造成硬盘空间不足,从而导致系统异常。 1、编写sh文件 #!/bin/bash ferp_logs_path="/usr/local/tomcat/apache-tomcat-8.0.24-fwone-erp/logs" ferp_fwone_path="${ferp_...
  • tomcat服务莫名其妙停止

    千次阅读 2018-11-30 10:09:18
    1. 服务停止 最初以为是jvm导致的,但是在/var/log并没有找到jvm致命错误日志(hs_err_pid.log) 又排除了GC情况,使用 jstat -gc pid 5000查看也没发现问题 最后还是从日志入手 原因:日志中存在不明进程销毁...
  • 启动:一般是执行sh tomcat/bin/startup.sh 停止:一般是执行sh tomcat/bin/shutdown.sh脚本命令 查看:执行ps -ef |grep tomcat 输出如下 *** 5144 。。。等等.Bootstrap start 说明tomcat已经正常启动, 5144 就为...
  • tomcat服务器莫名停止服务的原因

    千次阅读 2018-05-18 16:24:30
    我们初学者朋友会不会遇到这么一个场景,就是在费了好大功夫配置好的tomcat服务器,也链接上了mysql,但是一段时间后再连上的时候却发现tomcat不在服务状态,什么没做但是却在tomcat的运行日志里面发现了报错信息,...
  • 我在使用springboot时,当代码有问题时,发现控制台打印下面信息: Connected to the target VM, address: '127.0.0.1:... 如果日志出现问题,那就是日志体系发生冲突了,可以参考这个思路,处理项目中日志异常问题。
  • Tomcat启动停止慢问题查找解决

    千次阅读 2018-03-01 18:46:29
      使用封装的tomcat组件进行web服务部署时,导致tomcat服务在服务启动和停止中用时比较长,结合tomcat的运行日志进行问题分析。 运行日志如下:   二、tomcat服务停止慢问题 1、现象 根据tomcat的运行日志...
  • 我部署在Linux系统上的JAVAEE项目正常运行的某一天开始,日志突然就不在文本上打印出来了,但在客户端上程序还是正常运行,只是无日志记录。并且日志文本文件还是...服务器正常运行,未停止过服务器,也未修改过代码。
  • tomcat 日志关闭和设置

    千次阅读 2016-07-14 11:59:26
    一是运行中的日志,它主要 记录 运行的一些信息,尤其是一些异常 错误 日志信息 。 二是 访问 日志信息,它 记录 的 访问 的 时间 , IP , 访问 的 资 料等相 关 信息。 2 Tomcat 日志配置 2.1 访问日志的配置 ...
  • tomcat异常日志分析及处理 日志信息如下: 2015-10-2918:39:49org.apache.coyote.http11.Http11Protocolpause 信息:PausingCoyoteHTTP/1.1onhttp-8088 2015-10-2918:39:50org.apache.catalina.core....
  • 记录一次解决日志文件过大的解决办法 当catalina.out文件大于2g时,不便于查看异常记录,给排查问题造成一定的困扰。因此为了避免此场景的发生,需优化日志记录。...3,采用log4j接管tomcat日志,以弥补tomca...
  • 安装完tomcat以后,通过8080端口访问服务器,即可看到以下页面。注意右手边有两个管理功能,Manager App 和 Host Manager。 直接点击Host Manager出现错误,如下 403 Access Denied You are not authorized...
  • 注:文章转载于:... Tomcat未正常启动,在Tomcat 输出日志catalina.out 以及配置的日志输出文件中均没有异常输出,但是项目并没有启动,此时应到localhost.2017-08-27.log 中查看。
  • 停止tomcat时报错 java.net.ConnectException: 拒绝连接 (Connection refused) 百度了一下,发现问题是启动本次 Tomcat 服务器之前“关闭”的 Tomcat 服务器没有被彻底关闭,因此才导致此异常的发生 我们可以通过...
  • tomcat运行一段时间后会自动关闭,并产生错误日志,怀疑是客户端访问同时读取大字段造成的问题,但是看不懂错误日志文档,求教如何分析问题,错误日志见附件 :cry: :cry:
  • INFO: Illegal access: this web application ...改为”dbcp” class=”org.apache.tomcat.dbcp.dbcp.BasicDataSource”> 后又在tomcat/lib下加入了 mysql-connector-java-5.1.7-bin.jar 此时reload后不再报错。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,247
精华内容 4,098
关键字:

tomcat异常停止日志