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<greg(a)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=f2db...
>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> greg(a)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
>>>>>>>>>>> greg(a)bx.psu.edu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Greg Von Kuster
>>>>>>>>> Galaxy Development Team
>>>>>>>>> greg(a)bx.psu.edu
>>>>>>>
>>>>>>> Greg Von Kuster
>>>>>>> Galaxy Development Team
>>>>>>> greg(a)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/