Ok, now it's the other install that doesn't work anymore.
Looks like a cuckoo's nest, they must be sharing something they
shouldn't, first arrived first served.
But I really don't see what's going wrong:
- They run from distinct galaxy copies
- They use different databases
- They use different file paths for their respective data
- They don't use the same ports
The only things they share to my knowledge is the machines they run on,
Apache and Python
If anyone has an idea on what is going wrong and is willing to share it,
I'll be forever grateful!
Regards
L-A
Louise-Amelie Schmitt wrote:
Hello, and sorry for the late reply
All the answers are yes, since it didn't stop working at all.
I fear transferring the data again now...
Hans-Rudolf Hotz wrote:
well, do it the hard way and start from "square one":
- is galaxy working out of the box (fresh checkout, using SQLite)
- is galaxy working out of the box (using a non-root user called
galaxy, using a fresh checkout downloaded and installed into the
galaxy user home directory and use PostgreSQL)
+ is it still working when you change to "require_login = True"
+ is it still working when you change to "use_remote_user = True"
at which point does it stop working?
Hans
Cheers,
L-A
Le vendredi 15 avril 2011 à 16:52 +0200, Louise-Amélie Schmitt a
écrit :
Ooops, this is very right, I totally forgot about that. It woud have
become problematic at some point I guess. Thank you for pointing this
out!
I changed it so the new database is associated with brand new
appropriate directories. (and dropped and re-created the db again)
But I
keep getting the same error message with supposedly nonexistent
histories.
Thanks again
L-A
Le vendredi 15 avril 2011 à 13:47 +0200, Hans-Rudolf Hotz a écrit :
On 04/15/2011 10:56 AM, Louise-Amélie Schmitt wrote:
Hi Hans, thanks for your reply.
- is your PostgreSQL database in sync with the database folder?
I'm sorry I'm not sure I get what you mean, what folder is it?
the folder where you keep the datasets, eg:
<your local path>/galaxy_dist/database/
and it particular
<your local path>/galaxy_dist/database/files/000/dataset_*.dat
if you have an empty PostgreSQL database, then there should also
be no
datasets.
Hans
- are you sure there is no second galaxy installation
accessing the
same PostgreSQL database?
Never been this sure of something before. :) I installed both
galaxy and
postgresql myself so I can guarantee there's ony one galaxy
install on
it.
- you mention, that you have started with an empty PostgreSQL
database, so this last question does probably not apply:
make sure
you have the right user names (you even run into trouble
with case
sensitivity) in your PostgreSQL database. We had troubles
when we
switched to external authentication: some users just
couldn't work
anymore, ie could not create new history items anymore.
The problem
was then solved by fixing their user names in the (MySQL)
database.
Yes, the username is properly created in the database when I log
in on
an empty database. We never used anything besides LDAP anyway.
Regards, Hans
Cheers,
L-A
On Apr 14, 2011, at 1:00 PM, Louise-Amélie Schmitt wrote:
The thing is, we use LDAP logging so we can't even access the
website
without logging in.
Moreover, when I logged in, I arrived on the data analysis
page where the
automatic "unnamed history" was obviously created in the
history panel.
I forgot to mention we have issues creating and deleting
histories, like,
we can't access some histories and everytime we delete
histories, two extra
unnamed histories are created. As I mentioned before, it is
also impossible
to load a dataset in any history, existing or not.
Do you think it could be linked to our using LDAP?
Thanks
L-A
On Thu, 14 Apr 2011 12:06:55 -0400, Greg Von
Kuster<g...@bx.psu.edu>
wrote:
On Apr 14, 2011, at 11:49 AM, Louise-Amélie Schmitt wrote:
Here is the result I got from the debug statements:
galaxy.web.controllers.library_common DEBUG 2011-04-14
17:46:02,286 ###
history: None
This is the problem - when you registered normally, a history
would have
been automatically created for you. But somehow you don't
have a
history -
no idea why / how this happened, but it is very unlikely this
is a
result
of a bug within Galaxy. Try logging out and logging in again
and a new
history should be created for you.
galaxy.web.controllers.library_common DEBUG 2011-04-14
17:46:02,286 ###
trans:<galaxy.web.framework.GalaxyWebUITransaction object at
0x29f40950>
galaxy.web.controllers.library_common DEBUG 2011-04-14
17:46:02,286 ###
trans.sa_session:<sqlalchemy.orm.scoping.ScopedSession
object at
0x19ab21d0>
Thanks again
L-A
Le jeudi 14 avril 2011 à 11:05 -0400, Greg Von Kuster a écrit :
I assume when you dropped the old database and recreated
the new,
empty database, you made sure the database connection
string in
universe_wsgi.ini was correctly set. if so, when you
started up
Galaxy, it would have created all of the required tables in
the new
database, and they would all be empty. When you first
registered as
the admin user, it would have automatically populated
several tables
with data, including the history table. One or more of
these things
must not have been successful.
To attempt to narrow down the problem, I'll need you to do the
following. Here are lines # 905 - 907 in
~/lib/galaxy/web/controllers/library-common.py
# Send the current history to the form to enable
importing
datasets from history to library
history = trans.get_history()
trans.sa_session.refresh( history )
Please add the following debug statements:
# Send the current history to the form to enable
importing
datasets from history to library
history = trans.get_history()
log.debug("### history: %s" % str( history ))
log.debug("### trans: %s" % str( trans ))
log.debug("### trans.sa_session: %s" %
str( trans.sa_session ))
trans.sa_session.refresh( history )
Stop and restart your Galaxy server after making the above
changes,
and reply back with the output of the debug statements.
Assuming you
start your Galaxy instance with:
sh run.sh
you'll see the results of the debug statements in the log
scrolling in
the window in which you started Galaxy.
Thanks
On Apr 14, 2011, at 10:46 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Thank you for answering. Please find the answers after each
question.
Le jeudi 14 avril 2011 à 10:19 -0400, Greg Von Kuster a
écrit :
Hello Louise,
I do not think this issue is related to the Galaxy eggs, but
instead looks like a data issue of some kind. Please
replly back
with answers to the following questions.
How did you create your database?
Couldn't have done it more simply ^^:
CREATE DATABASE "galaxy_db";
GRANT ALL ON DATABASE "galaxy_db" TO "galaxy";
executed in psql.
The very same way I did for the one that's still working
fine.
Did you populate it with any data exported from another
database?
In the beginning yes but when I saw that error I dropped the
database
and re-created it again, to start anew and test on an empty
database. I
even created a brand new test database to see if the issue
wasn't
related to stuff remaining after dropping the database,
but it
turned
out badly too.
What version of Galaxy are you using?
The latest dist, cause when I saw how things were turning
out I hg
pulled and updated hoping it would fix the issue. I did
that this
morning.
What database are you using?
PostgreSQL, as recommended in the doc.
Greg Von Kuster
Cheers,
L-A
On Apr 14, 2011, at 5:38 AM, Louise-Amélie Schmitt wrote:
Hello everyone
I have an issue when trying to import new datasets or when
putting a
dataset into a history. I saw Edward Kirton had the same
problem
but he
got no answer:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-May/002732.html
Here is the error message I get when clicking the "Add
datasets"
button
in a library, in the admin's "Manage data libraries" panel:
UnmappedInstanceError: Class '__builtin__.NoneType' is not
mapped
URL:
http://manni/galaxy/library_common/upload_library_dataset?library_id=f2db41e1fa331b3e&show_deleted=False&cntrller=library_admin&folder_id=f2db41e1fa331b3e&use_panels=False
File
'/g/funcgen/galaxy/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py',
line 364 in respond
app_iter = self.application(environ, detect_start_response)
File
'/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py',
line 98 in __call__
environ, self.app)
File
'/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py',
line
539 in intercept_output
app_iter = application(environ, replacement_start_response)
File
'/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/recursive.py',
line 80 in __call__
return self.application(environ, start_response)
File
'/g/funcgen/galaxy/lib/galaxy/web/framework/middleware/remoteuser.py',
line 109 in __call__
return self.app( environ, start_response )
File
'/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py',
line 632 in __call__
return self.application(environ, start_response)
File
'/g/funcgen/galaxy/lib/galaxy/web/framework/base.py', line
145 in
__call__
body = method( trans, **kwargs )
File
'/g/funcgen/galaxy/lib/galaxy/web/controllers/library_common.py',
line 907 in upload_library_dataset
trans.sa_session.refresh( history )
File
'/g/funcgen/galaxy/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/orm/scoping.py',
line 127 in do
return getattr(self.registry(), name)(*args, **kwargs)
File
'/g/funcgen/galaxy/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/orm/session.py',
line 925 in refresh
raise exc.UnmappedInstanceError(instance)
UnmappedInstanceError: Class '__builtin__.NoneType' is not
mapped
Now when does it occur:
I have two databases. One test database I created a
month ago
which
works fine, even now. The other one I created recently
which is
supposed
to be the final database. But the latter keeps
triggering the
above
message, even when I drop it and create it all over
again. I
even tried
to create a third one, all clean and new but the problem
remains. I
tried to trash all the eggs so Galaxy gets fresh new
eggs, with
no
effect at all. The error's still there.
If you have any clue, I'll be forever grateful.
Cheers,
L-A
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Greg Von Kuster
Galaxy Development Team
g...@bx.psu.edu
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Greg Von Kuster
Galaxy Development Team
g...@bx.psu.edu
Greg Von Kuster
Galaxy Development Team
g...@bx.psu.edu
Greg Von Kuster
Galaxy Development Team
g...@bx.psu.edu
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
