v6 stop_after_init does not exit

[Ferdinand]

please see last comment on
https://bugs.launchpad.net/openobject-server/5.0/+bug/574874
can not change the status of the bug there

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Dr. Ferdinand,

I have checked this issue with version 6 stable and trunk both but I did not face any problem in stop_after_init option.
I have faces traceback related to YML but that is again a another issue.

So stop_after_init option is working properly at my end, Would you please provide me the steps to reproduce the problem.

Thanks and waiting for your reply.

[Ferdinand (office-chricar)]

as I said , it hangs with one db but not with another.
may be you can sse something relevant in the log file

[Olivier Dony (Odoo) (odo-openerp)]

Hello,

The usual cause for --stop-after-init failing to stop the process is that other background threads are active in the server, and either currently processing requests, or failing to appropriately react to the shutdown procedure.

Looking at your startup logs, we can see at least 2 things that are starting background threads:
 - document_ftp modules starts at 11:00:16,412, but it fails to open the listening socket because the 8021 is already in use. This module normally uses timeout to react to shutdown events in a timely manner anyway.
 - pyro: the pyro module starts at 11:00:16,099 and it opens a listening socket on port 8072. Perhaps this service does not properly handling shutdown events?
- there are perhaps other custom modules in your database that run background threads as well...?

Some things you could do to narrow down the problem:
- make a copy of the database with the issue, then disable the pyro module or uninstall it temporarily, and see if that makes the problem go away. Do the same with any other suspected module
- alternatively, make a copy of a database that does not have the problem, then add the suspicious modules one by one, and see which one makes it fail the --stop-after-init

I suppose replacing the sys.exit() (graceful termination) with an os._exit() (hard process kill) would be a valid way to make the problem go away in the case of --stop-after-init. Normally only the initialization of the server has been done, and it should not be servicing requests, so a hard kill would not do much harm. But I'd like to avoid such a solution, because it would only hide the issue in the case of --stop-after-init, but still requiring a hard kill (or double ctrl-c) every time to shutdown the server when it is running in normal mode. I'd rather have all modules with background threads behave as good citizens when it comes to background threads.

[Ferdinand (office-chricar)]

Thanks
I have removed pyro and docuemnt_ftp without change of behaviour

but I found
https://bugs.launchpad.net/openobject-server/+bug/828046

could it be possilbe that a malformed po file is not closed correctly ?

[Olivier Dony (Odoo) (odo-openerp)]

No, malformed PO (if there were any) cannot cause this behavior, because they are not loaded or parsed in separate threads.
You're looking for a module that spawns background threads that never stop running, possibly waiting for requests to service.

As you seem to have databases that do not exhibit this behavior, you could compare the list of installed modules between them.

One last thing you can try is to signal the OpenERP server process with a "QUIT" signal, either by hitting CTRL+4 on the terminal where the server is currently running (as a *foreground* process), or by using "sudo kill -3 <PID>" where <PID> is the process ID of the openerp-server process. This will cause the server to write in the log a dump of all the threads that are currently running. This will give us clues as to what module they come from (disclaimer: we're getting very technical here ;-)).
You would need to first remove the os._exit() line of your patch, to give you some time to send the signal before stopping the process the hard way.

[Ferdinand (office-chricar)]

Does this trace help (removed the translation messages)
root@cc-hp:/var/log# grep -v translate debug
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:psycopg2:installed. Logging using Python logging module
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:web-services:Registered an exported service: db
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:web-services:Registered an exported service: common
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:web-services:Registered an exported service: object
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:web-services:Registered an exported service: wizard
Aug 18 13:25:35 cc-hp OpenERP Server 6.0.2:?:DEBUG:web-services:Registered an exported service: report
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:web-services:Registered an exported service: report
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.TxtIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.PptxIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.DocIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.DocxIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.XlsxIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.PdfIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.ImageNoIndex>
Aug 18 13:25:38 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:addons.document.content_index:Register content indexer: <indexer document.std_index.OpenDoc>
Aug 18 13:26:35 cc-hp OpenERP Server 6.0.2:chricar6:DEBUG:netsvc.agent:Run ir.cron._poolJobs(*('chricar6',), **{})

[Olivier Dony (Odoo) (odo-openerp)]

On 08/18/2011 01:31 PM, Ferdinand @ Camptocamp wrote:
> Does this trace help (removed the translation messages)
> root@cc-hp:/var/log# grep -v translate debug

Thanks but no, it only shows the usual services starting up, nothing surprising. At this point we'd really need a dump of the threads running when the server doesn't want to exit (i.e. taken with SIGQUIT signal), or to find out exactly which module in your databases causes this behavior to appear.

[xrg (xrg)]

On Tuesday 23 August 2011, you wrote:
> On 08/18/2011 01:31 PM, Ferdinand @ Camptocamp wrote:
> > Does this trace help (removed the translation messages)
> > root@cc-hp:/var/log# grep -v translate debug
>
> At this point we'd really need a dump of the threads running
> when the server doesn't want to exit (i.e. taken with SIGQUIT signal),
> or to find out exactly which module in your databases causes this
> behavior to appear.

http://git.hellug.gr/?p=xrg/openobject-server;a=commitdiff;h=68087a9cc89d3dfc

Sun, 27 Jun 2010

[Launchpad Janitor (janitor)]

[Expired for OpenERP Server because there has been no activity for 60 days.]