Re: [Gnumed-bugs] GNUmed 1.5.0 - 'module' object has no attribute 'Json' - bug or user error ?

[Karsten Hilbert]

On Tue, Jan 13, 2015 at 09:21:09AM +0100, Karsten Hilbert wrote:

> > Further to the above, by way of an experiment to see if I could get *any* 
> > fixups to work,
> > 
> > I went back to the fixups which I had last run successfully, which came 
> > from server 19.8 which I had run back around May or June of 2014.
> > 
> > But when I tried to re-run them as follows,
> > 
> >         dhcp-128-189-241-105:bootstrap root# cd 
> > /Users/djb/Downloads/gnumed-server.19.8/server/bootstrap/
> >         dhcp-128-189-241-105:bootstrap root# sh ./fixup-db.sh 19
> > 
> > in the hope of achieving simple confirmation that these particular ones had 
> > already been run, the session appeared to "hang" …
> > 
> >     ===========================================================
> >     Fixing GNUmed database.
> > 
> >     This will apply fixups to an existing GNUmed database of
> >     version 19 named "gnumed_v19".
> >     ===========================================================
> > 
> >     1) applying fixes to database ...
> >     Adjusting PYTHONPATH ...
> >     =======================================
> >     Bootstrapping GNUmed database system...
> >     =======================================
> >     You are about to install the following parts of GNUmed:
> >     -------------------------------------------------------
> >     bundle "v19-fixups" in <gnumed_v19> (or overridden) on <>
> >     -------------------------------------------------------
> >     This will update an existing GNUmed database.
> > 
> >     It does so by applying all fixup SQL scripts
> >     appropriate to the version of the database.
> > 
> >     Do you really want to install this database setup ?
> >     Type yes or no: yes
> >     ==> bootstrapping "v19-fixups" ...
> >     I need the password for the database user [postgres].
> >     Please type the password:
> >     ==> using pre-existing *target* database [gnumed_v19] ...
> >     ==> transferring users ...
> >         ... skipped (disabled)
> > 
> > (waited 20 minutes before aborting)
> > 
> > 
> > Is there a problem in what I was trying to do?
> 
> No, looks correct to me.
> 
> I have no idea why it seems to hand. Maybe it just takes that
> long. One would have to investigate whether it appears to be
> doing anything or not.

One would look at the process list (with something like
lsof/htop under Linux) and at

        select * from pg_stat_activity;

inside the database while the script is running.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346