Re: [Gnumed-devel] Bootstrap fails on Ubuntu Lucid

[Karsten Hilbert]

On Thu, Jun 17, 2010 at 06:52:00AM +0400, Евгений Кузнецов wrote:

> > If you feel adventurous you can go find the file
> >
> >        pycommon/gmPsql.py
> > [...]
> > Then change the lines inside that function to look like this:
> > [...]
> > After that the actual error will be shown on the console
> > where you started gm-bootstrap_server and you could report
> > that to us (here on this list).
> 
> Done just that, now the bootstraping process goes further than before.

Indeed.

> The output is quite long (there's quite a way from v2 to v13), so I
> redirected it to a separate file (attached). Despite running the
> command as "gm-bootstrap_server > console_output", it still drops the
> following into the console:
>
> /var/lib/gnumed/Gnumed/pycommon/gmTools.py:11: DeprecationWarning: the
> MimeWriter module is deprecated; use the email package instead
>   import urllib2 as wget, decimal, StringIO, MimeWriter, mimetypes, mimetools
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
>     msg = self.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
>     return fmt.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 448, in format
>     s = s + record.exc_text
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position
> 354: ordinal not in range(128)
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
>     msg = self.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
>     return fmt.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 448, in format
>     s = s + record.exc_text
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position
> 354: ordinal not in range(128)
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
>     msg = self.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
>     return fmt.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 448, in format
>     s = s + record.exc_text
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position
> 354: ordinal not in range(128)
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
>     msg = self.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
>     return fmt.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 448, in format
>     s = s + record.exc_text
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position
> 354: ordinal not in range(128)
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
>     msg = self.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
>     return fmt.format(record)
>   File "/usr/lib/python2.6/logging/__init__.py", line 448, in format
>     s = s + record.exc_text
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position
> 354: ordinal not in range(128)

That's all fine. It is Python dumping to the console the
problem we are working around. If you want to capture that
as well you'd need to redirect stderr, too.

However, the console_output you sent did contain what we
were after. It did show two non-fatal, old (v9 -> v10)
problems which I now fixed.

Due to it now running all the way to the end things worked
fine.

> To my great pity, it's impossible to know whether all this results in
> a working server config or not,

It did. The bootstrap*.log you send did contain the lines ...

2010-06-17 00:19:58  DEBUG     gm.cfg 
(/var/lib/gnumed/Gnumed/pycommon/gmCfg2.py::get() #314): option [database 
gnumed_v13::target version] found in source [file]
2010-06-17 00:19:59  INFO      gm.db 
(/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::database_schema_compatible() #455): 
detected schema version [v13], hash [fab7c1ae408a6530c47f9b5111a0841e]
2010-06-17 00:19:59  INFO      gm.bootstrapper 
(./bootstrap_gm_db_system.py::verify_result_hash() #968): database identity 
hash properly verified

... which mean all is well at the end.

However, the log also contains ...

2010-06-17 00:19:59  INFO      gm.bootstrapper 
(./bootstrap_gm_db_system.py::check_holy_auth_line() #883): hba file: 
/etc/postgresql/8.4/main/pg_hba.conf
2010-06-17 00:19:59  INFO      gm.bootstrapper 
(./bootstrap_gm_db_system.py::check_holy_auth_line() #902): did not find 
standard GNUmed authentication directive in pg_hba.conf
2010-06-17 00:19:59  INFO      gm.bootstrapper 
(./bootstrap_gm_db_system.py::check_holy_auth_line() #903): regex: 
local.*samegroup.*\+gm-logins

... which will prevent you from connecting to your brand new
database (even if the client were to run).

What to do about this is explained here:

        http://wiki.gnumed.de/bin/view/Gnumed/ConfigurePostgreSQL

under "4) Database Access Rights Setup".

> since after this procedure GNUmed
> client segfaults on attempt to run it (it has run OK before):
> 
> /usr/share/gnumed/Gnumed/pycommon/gmTools.py:11: DeprecationWarning:
> the MimeWriter module is deprecated; use the email package instead
>   import urllib2 as wget, decimal, StringIO, MimeWriter, mimetypes, mimetools
> DISPATCHER WARNING: connect(): unknown signal [test_result_mod_db]
> DISPATCHER WARNING: connect(): unknown signal [substance_intake_mod_db]
> 
> ** (python:17057): CRITICAL **: menu_proxy_module_load: assertion
> `dbusproxy != NULL' failed
> /usr/bin/gnumed: строка 45: 17057 Ошибка сегментирования
>     python -m Gnumed.gnumed ${OPTIONS}
> 
> Where the last line is Russian for "/usr/bin/gnumed: line 45: 17057
> Segmentation fault"

This very very likely has to do with a below-GNUmed system
libraries problem. Sebastian is currently looking into
reproducing this.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346