backup database gives zero size file

[Cuong]

Hi,

I tested with backup db function, and it gives zero file size.
openerp-web: revno: 2019

Thanks,

[Vishal Parmar(Open ERP) (vpa-openerp)]

Hello Cuong,

I have checked your issue with updated code for trunk(6.1) but I didn't face any problem as you have describe in your specification. I have attached a video for it so would you please check it and informed us where you faced
the problem.

Thanks and waiting for your reply.

[Cuong (bhcuong2008)]

Hi Vishal,

I send you my video. All 3 browsers FF 9.01 (Ubuntu + Win 7), Chrome 16 gave the same result.

openerp-server informs successfully.

Thanks,

[Vishal Parmar(Open ERP) (vpa-openerp)]

Hello Cuong,

I have checked again your issue with FF 9.0.1,Chrome 16 with Ubuntu and window 7 and It's show me correct file size at my end. I have attached a video would you please check it and try again with updated code and informed us still you have faced the same problem.

Thanks and waiting for your reply.

[Cuong (bhcuong2008)]

Hi,

With the latest rev web 2023, server 3975, I still face this issue. One thing you can check this for me, that is web is run as a module within server or independent application through xmlrpc?

Currently, my openerp-web is run separately from openerp-server.

Thanks,

[Cuong (bhcuong2008)]

Hi Vishal,

This is my log at openerp-web
===
[2012-01-21 18:01:16,876] DEBUG:web.common.http:Dispatching to /web/database <web.controllers.main.Database object at 0x25ad3d0> backup
[2012-01-21 18:01:16,878] DEBUG:web.common.http:POST --> Database.backup {}
[2012-01-21 18:01:17,094] DEBUG:web.common.http:<-- <Response 0 bytes [200 OK]>
[2012-01-21 18:01:17,095] INFO:werkzeug:192.168.1.131 - - [21/Jan/2012 18:01:17] "POST /web/database/backup HTTP/1.1" 200 -
===

Thanks,

[Xavier (Open ERP) (xmo-deactivatedaccount)]

> Currently, my openerp-web is run separately from openerp-server.

I generally run my web client in this configuration as well.

> This is my log at openerp-web

Does db backup work from the GTK client? Can you start your server in debug_rpc_answer and see what happens? Because I really have trouble seeing what could fail considering how little there is in the backup method on the web client side, it's just a very thin wrapper against the corresponding server method:

    @openerpweb.httprequest
    def backup(self, req, backup_db, backup_pwd, token):
        db_dump = base64.b64decode(
            req.session.proxy("db").dump(backup_pwd, backup_db))
        return req.make_response(db_dump,
            [('Content-Type', 'application/octet-stream; charset=binary'),
             ('Content-Disposition', 'attachment; filename="' + backup_db + '.dump"')],
            {'fileToken': int(token)}
        )

[Cuong (bhcuong2008)]

Hi Xavier,

This is the log at openerp-server with debug_rpc_answer mode. I dont have GTK client for version 6.1rc so I cant test it. I used GTK 6.0.3 to test, and had the same result of zero file size.

===
[2012-01-23 12:24:40,992][?] DEBUG_RPC:service:db.dump('admin', 'test_03')
[2012-01-23 12:24:41,199][?] INFO:web-services:DUMP DB: test_03
[2012-01-23 12:24:41,200][?] DEBUG_RPC_ANSWER:execution time:'0.207s'
[2012-01-23 12:24:41,200][?] DEBUG_RPC_ANSWER:result:''
[2012-01-23 12:24:41,200][?] INFO:werkzeug:127.0.0.1 - - [23/Jan/2012 12:24:41] "POST /xmlrpc/db HTTP/1.1" 200 -
[2012-01-23 12:24:56,878][?] DEBUG:cron:Database 'test_03' wake-up! Firing multi-threaded cron job processing
[2012-01-23 12:24:57,003][?] DEBUG:cron:Cron execution thread for job `Email Queue Manager` spawned
[2012-01-23 12:24:57,007][?] DEBUG:cron:object.execute('test_03', 1, '*', u'mail.message', u'process_email_queue')
[2012-01-23 12:24:57,025][?] DEBUG:execution time:0.018s (mail.message, process_email_queue)
[2012-01-23 12:24:57,059][?] DEBUG:cron:object.execute('test_03', 1, '*', u'osv_memory.autovacuum', u'power_on')
[2012-01-23 12:24:57,060][?] DEBUG:cron:Cron execution thread for job `AutoVacuum osv_memory objects` spawned
[2012-01-23 12:24:57,065][?] DEBUG:execution time:0.005s (osv_memory.autovacuum, power_on)
[2012-01-23 12:24:57,079][?] DEBUG:cron:Wake-up scheduled for database 'test_03' @ 1327658347
[2012-01-23 12:24:57,080][?] DEBUG:cron:Going to sleep for 60s
[2012-01-23 12:24:57,081][?] DEBUG:cron:Wake-up scheduled for database 'test_03' @ 1327322688
[2012-01-23 12:24:57,081][?] DEBUG:cron:Wake-up scheduled for database 'test_03' @ 1327321742
[2012-01-23 12:24:57,097][?] WARNING:db.cursor:Cursor not closed explicitly
Please enable sql debugging to trace the caller.
[2012-01-23 12:25:57,137][?] DEBUG:cron:Going to sleep for 60s
===

Log at postgresql server has just 2 lines:
===
2012-01-23 19:34:23 ICT LOG: could not receive data from client: Connection reset by peer
2012-01-23 19:34:23 ICT LOG: could not receive data from client: Connection reset by peer
===

Thanks,

[Cuong (bhcuong2008)]

Hi Xavier,

Any news about this issue? Could you tell other community members to test backup function?

Thanks,

[Xavier (Open ERP) (xmo-deactivatedaccount)]

> Any news about this issue?

Nope, I forwarded this to the server team as that seems to be an issue there (both clients are affected in similar ways and don't do much — if anything — besides calling some RPC method.

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

As indicated on the duplicate bug 790164, this is most likely caused by a non-standard authentication method for PostgreSQL on Ubuntu. You can try to update the server to revision [1] or create a $HOME/.pgpass file as explained in [2].

For the record, here is the comment I posted on bug 790164:
Update: a recent change in trunk should make the situation less confusing. Having a zero bytes dump was usually the consequence of using non-default PostgreSQL access control on Unix (the default 'ident' authentication failed).
A fix has landed in trunk [1] and the system should now properly report these cases as errors (instead of saying the backup was successful), and it should also automatically try to use the password configured in the configuration file.
This method may still fail (this is a call to the external pg_dump/pg_restore commands) so in that case you should double-check the pg_path config variable and try to create a $HOME/.pgpass (Unix) or %APPDATA%\postgresql\pgpass.conf (Windows) as explained in the PostgreSQL documentation [2].

[1] server trunk (6.1) revision 3992 rev-id: <email address hidden>
[2] http://www.postgresql.org/docs/8.4/static/libpq-pgpass.html

Thanks for reporting!