Changes between Initial Version and Version 1 of Ticket #787, comment 2


Ignore:
Timestamp:
12/09/16 23:34:47 (7 years ago)
Author:
David Sommerseth
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #787, comment 2

    initial v1  
    55}}}
    66
    7 So what seems to happen here is that some kind of interrupt happening while OpenVPN is doing the event_wait() call in io_wait_dowork().  Most likely it is a signal happening.  But that smells like a signal we're not normally catching, as I'd expect a different behaviour in those cases.  But it is interesting that it is a controlled shutdown.  The signals which causes that are normally SIGINT and SIGTERM and SIGINT, the other signals we catch normally dumps some statistics, reconnects and similar "keep the process running" operations.
     7So what seems to happen here is that some kind of interrupt happening while OpenVPN is doing the event_wait() call in io_wait_dowork().  Most likely it is a signal happening.  But that smells like a signal we're not normally catching, as I'd expect a different behaviour in those cases.  But it is interesting that it is a controlled shutdown.  The signals which causes that are normally SIGINT and SIGTERM. The other signals we catch normally dumps some statistics, reconnects and similar "keep the process running" operations.
    88
    99I think you need to look at increasing the log level to 9.  And perhaps even try to run OpenVPN through gdb with a trigger to break the run when status < 0 when returning from event_wait() in forward.c:1611.  To have a look at the backtrace to see what the process is doing exactly when this happens.