openerp-india team mailing list archive

[risto3 <952286@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I'd like to get openerp working well with SMF but the first thing I
notice is that it chokes instead of a graceful shutdown with signal
<pid> or signal -INT <pid>

Here is the output:
2012-03-11 14:35:03,559 6909 INFO ? openerp.netsvc: Stopping 1 services
Traceback (most recent call last):
  File "server/6.1/openerp-server", line 270, in <module>
    quit_on_signals()
  File "server/6.1/openerp-server", line 207, in quit_on_signals
    openerp.service.stop_services()
  File "/home/richard/src/openerp/server/6.1/openerp/service/__init__.py", line 82, in stop_services
    openerp.netsvc.Server.quitAll()
  File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 317, in quitAll
    srv.stop()
  File "/home/richard/src/openerp/server/6.1/openerp/service/netrpc_server.py", line 142, in stop
    self._close_socket()
  File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 327, in _close_socket
    close_socket(self.socket)
  File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 50, in close_socket
    sock.shutdown(socket.SHUT_RDWR)
  File "<string>", line 1, in shutdown
socket.error: [Errno 134] Ce destinataire n'est pas connecté.

from line 147 to 208 in openerp-server describes the supposed handling,
notably what is supposed to happen:
    """ Wait for one or two signals then shutdown the server.

    The first SIGINT or SIGTERM signal will initiate a graceful shutdown while
    a second one if any will force an immediate exit.

    """
    # Wait for a first signal to be handled. (time.sleep will be interrupted
    # by the signal handler.) The try/except is for the win32 case.

This is considered a showstopper in order to put into production mode as
is considered 'unmanageable'.

** Affects: openobject-server
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/952286

Title:
  signal problems prevent graceful shutdown

Status in OpenERP Server:
  New

Bug description:
  I'd like to get openerp working well with SMF but the first thing I
  notice is that it chokes instead of a graceful shutdown with signal
  <pid> or signal -INT <pid>

  Here is the output:
  2012-03-11 14:35:03,559 6909 INFO ? openerp.netsvc: Stopping 1 services
  Traceback (most recent call last):
    File "server/6.1/openerp-server", line 270, in <module>
      quit_on_signals()
    File "server/6.1/openerp-server", line 207, in quit_on_signals
      openerp.service.stop_services()
    File "/home/richard/src/openerp/server/6.1/openerp/service/__init__.py", line 82, in stop_services
      openerp.netsvc.Server.quitAll()
    File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 317, in quitAll
      srv.stop()
    File "/home/richard/src/openerp/server/6.1/openerp/service/netrpc_server.py", line 142, in stop
      self._close_socket()
    File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 327, in _close_socket
      close_socket(self.socket)
    File "/home/richard/src/openerp/server/6.1/openerp/netsvc.py", line 50, in close_socket
      sock.shutdown(socket.SHUT_RDWR)
    File "<string>", line 1, in shutdown
  socket.error: [Errno 134] Ce destinataire n'est pas connecté.

  from line 147 to 208 in openerp-server describes the supposed handling,
  notably what is supposed to happen:
      """ Wait for one or two signals then shutdown the server.

      The first SIGINT or SIGTERM signal will initiate a graceful shutdown while
      a second one if any will force an immediate exit.

      """
      # Wait for a first signal to be handled. (time.sleep will be interrupted
      # by the signal handler.) The try/except is for the win32 case.

  This is considered a showstopper in order to put into production mode
  as is considered 'unmanageable'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/952286/+subscriptions