though at present it looks like my query for the last of the three is rather inefficient :P
2013-11-19 32329, 2013
JonnyJD_ joined the channel
2013-11-19 32339, 2013
rvedotrc joined the channel
2013-11-19 32315, 2013
uk_ has left the channel
2013-11-19 32325, 2013
DWSR2
Hey, getting Caught exception in MusicBrainz::Server::Controller::Root->begin "stash takes a hash or hashref at /usr/lib/perl5/Class/MOP/Method/Wrapped.pm line 162" when accessing my local mirror. Just did a clean import of the database and restarted jetty as well, seems to give me the same thing.
2013-11-19 32318, 2013
ianmcorvidae
what page, do you have a full stacktrace?
2013-11-19 32305, 2013
ianmcorvidae
alternatively, if you can bisect it that'd help (check out v-2013-10-14 and if it works there you can do 'git bisect good v-2013-10-14' and 'git bisect bad <whatever you currently have checked out that's failing>' and then it'll check things out for you and you can issue 'git bisect bad' or 'git bisect good' as applies with each)
2013-11-19 32330, 2013
ianmcorvidae
since this is a VM I'm not sure it could be something like a dependency thing, so
2013-11-19 32313, 2013
ianmcorvidae
(if you can't find a pre-schema-change good revision then bisection won't work though)
ianmcorvidae: What service do I need to restart between checkouts
2013-11-19 32325, 2013
DWSR2
ianmcorvidae: I resorted to restarting the whole box last time.
2013-11-19 32330, 2013
ianmcorvidae
ah
2013-11-19 32301, 2013
ianmcorvidae
I'd restart memcached (which is probably /etc/init.d/memcached restart) and musicbrainz-server (which would be sudo svc -t /etc/service/musicbrainz-server/ I think)
2013-11-19 32340, 2013
ianmcorvidae
I think I may have found something, but
2013-11-19 32318, 2013
DWSR2
ianmcorvidae: Welp, that seems to have caused the web server to just die.
/etc/service/musicbrainz-server/run is the script it should be running to start the server
2013-11-19 32303, 2013
DWSR2
and not found.
2013-11-19 32343, 2013
DWSR2
I guess I'll just restart the box?
2013-11-19 32352, 2013
ianmcorvidae
yeah, I guess so
2013-11-19 32353, 2013
DWSR2
Also I got a bunch of warnings when I did the database import that only the superuser or database admin user could vacuum the DB, but I followed the instructions in INSTALL.md to the letter in regards to doing an import.
2013-11-19 32302, 2013
ianmcorvidae
yeah, for those tables it's fine
2013-11-19 32317, 2013
ianmcorvidae
assuming it's mostly for the postgresql main tables
2013-11-19 32329, 2013
DWSR2
t'was, yes.
2013-11-19 32333, 2013
ianmcorvidae
(that happens any time, anyway -- if you get something like that for one of the MB tables, say, artist, then it's potentially an issue)
2013-11-19 32312, 2013
DWSR2
nope, still nothing from the server.
2013-11-19 32325, 2013
ianmcorvidae
presumably check out the revision you were using before, then, if you can't find yourself a log that tells you what it's doing
2013-11-19 32326, 2013
DWSR2
welp, I at least get a 500 now.
2013-11-19 32353, 2013
ianmcorvidae
the same one?
2013-11-19 32301, 2013
DWSR2
yes
2013-11-19 32307, 2013
DWSR2
I checked out 2013-11-11
2013-11-19 32313, 2013
DWSR2
Gonna try 2013-10-28
2013-11-19 32351, 2013
DWSR2
2013-10-28 gives me the same internal error
2013-11-19 32304, 2013
DWSR2
And 2013-10-14 gives me a broken server.
2013-11-19 32332, 2013
ianmcorvidae
yeah
2013-11-19 32357, 2013
DWSR2
No error logs with it, btw.
2013-11-19 32309, 2013
ianmcorvidae
okay; with the note that this is exclusively for testing a hypothesis, it may at least not ISE if you change REPLICATION_TYPE to RT_STANDALONE in DBDefs
2013-11-19 32335, 2013
ianmcorvidae
I think this has to do with the thing that's intended to display the last replication date on slave servers
2013-11-19 32340, 2013
ianmcorvidae
haven't really determined further than that, heh
2013-11-19 32344, 2013
ianmcorvidae
(and can't reproduce it)
2013-11-19 32303, 2013
DWSR2
mkay, restarting the daemon
2013-11-19 32334, 2013
DWSR2
seems to work
2013-11-19 32308, 2013
ianmcorvidae
okay, well, that does at least suggest my hypothesis is right
2013-11-19 32318, 2013
DWSR2
now, if I only need this to run headphones against, do I need to set up a search server?
2013-11-19 32345, 2013
ianmcorvidae
I'd generally recommend it, otherwise it's passing the search requests on to the main MB search server, which is then prone to ratelimit you
2013-11-19 32305, 2013
ianmcorvidae
note that with REPLICATION_TYPE set to RT_STANDALONE you can't replicate new packets, so that's probably not a permanent solution
2013-11-19 32322, 2013
DWSR2
No, but I can always manually dump and reimport the DB once a week or so.
2013-11-19 32331, 2013
DWSR2
That's not the end of the world.
2013-11-19 32339, 2013
marcooliveira joined the channel
2013-11-19 32342, 2013
ianmcorvidae
heh, I suppose if you're fine with that then okay :P
2013-11-19 32304, 2013
DWSR2
I'm running this so that I can be nice and not hammer the main MB server.
2013-11-19 32304, 2013
ianmcorvidae
that does also give you a convenient time for rebuilding search indexes and such
2013-11-19 32334, 2013
DWSR2
I should be able to access an artist by its MBid without a search server, correct?
2013-11-19 32300, 2013
DWSR2
i.e. mb.org/artist/<id> -->> localhost:5000/artist/<id> should give me the same thing, correct?
2013-11-19 32311, 2013
ianmcorvidae
yeah, assuming equivalent database state
2013-11-19 32337, 2013
DWSR2
How often to mbids for artists change (I'm going to assume close to never)?
2013-11-19 32302, 2013
ianmcorvidae
merges can change the quasi-canonical MBID, but everything will redirect
2013-11-19 32319, 2013
DWSR2
ok, because none of that seems to be working
2013-11-19 32320, 2013
ianmcorvidae
that suggests you had a bad DB import, I guess, if you're getting 404s on artists that are old enough there's no reason for them not to exist
2013-11-19 32336, 2013
ianmcorvidae
(not sure if that's the problem you're having, but)
2013-11-19 32334, 2013
kepstin_ joined the channel
2013-11-19 32353, 2013
DWSR2
They're just saying not found, so I would assume this is a nicely dressed 404.
2013-11-19 32357, 2013
DWSR2
That you have to take out to dinner.
2013-11-19 32301, 2013
ianmcorvidae
:P
2013-11-19 32308, 2013
ianmcorvidae
so yeah, that suggests a bad DB import
2013-11-19 32319, 2013
DWSR2
mkay, sec, let me see if all the sigs match
2013-11-19 32339, 2013
ianmcorvidae
it'd probably be a detail somewhere in the output of the import process
2013-11-19 32359, 2013
ianmcorvidae
(if it's a bad import, I mean)
2013-11-19 32345, 2013
ianmcorvidae
semi-likely situation would be the VM ran out of disk space (as I mentioned the other night, you need roughly 2x the size of a fully-imported DB at the highest-usage step of the import)
2013-11-19 32346, 2013
DWSR2
might as well start from the source.
2013-11-19 32355, 2013
DWSR2
It's a 300GB disk.
2013-11-19 32302, 2013
ianmcorvidae
if you resized the in-VM disk then okay (it won't automatically grow to the constraints of the host system)
2013-11-19 32315, 2013
DWSR2
The server is on bare metal.
2013-11-19 32330, 2013
DWSR2
Just for context.
2013-11-19 32335, 2013
ianmcorvidae
you were saying VM the other night and haven't corrected me in this conversation when I've said VM :P
2013-11-19 32347, 2013
DWSR2
Fair point.
2013-11-19 32331, 2013
DWSR2
Anyway, it would appear that the data is correct, let's dump and reimport, I guess:?
2013-11-19 32336, 2013
DWSR2
Hopefully won't take too long.
2013-11-19 32339, 2013
ianmcorvidae
that increases the probability of some sort of version mismatch for something or other
2013-11-19 32355, 2013
ianmcorvidae
did you keep a log from the import process?
2013-11-19 32302, 2013
ianmcorvidae
if so it is likely to have hints
2013-11-19 32303, 2013
DWSR2
No, is one automatically generated?
2013-11-19 32313, 2013
ianmcorvidae
no
2013-11-19 32331, 2013
DWSR2
Then I will this time. Is there a switch to the import script that will tell it to output to a file?
2013-11-19 32334, 2013
ianmcorvidae
well, InitDb --echo will output what I'm referring to, but if you didn't redirect that into a file then it's tied to that terminal
2013-11-19 32340, 2013
ianmcorvidae
no, just use a pipe
2013-11-19 32345, 2013
DWSR2
k
2013-11-19 32346, 2013
ianmcorvidae
| tee whatever.log
2013-11-19 32351, 2013
DWSR2
yeah.
2013-11-19 32311, 2013
ianmcorvidae
you might check the actual in-database data, I guess, if you didn't
2013-11-19 32324, 2013
ianmcorvidae
select * from artist where gid = '<whatever MBID you were using>'
2013-11-19 32343, 2013
ianmcorvidae
and/or select * from artist_gid_redirect where gid = '<whatever MBID>'
2013-11-19 32311, 2013
DWSR2
nothing nothing.
2013-11-19 32314, 2013
DWSR2
Sounds like a bad import then
2013-11-19 32352, 2013
ianmcorvidae
yeah, you might even just do a select * from artist limit 10; to see if there's *any* data in the artist table
2013-11-19 32307, 2013
ianmcorvidae
likely not, if you have a bad import, but
2013-11-19 32313, 2013
ianmcorvidae
helps to confirm that hypothesis
2013-11-19 32327, 2013
DWSR2
nope.
2013-11-19 32333, 2013
DWSR2
Nothing there.
2013-11-19 32336, 2013
ianmcorvidae
note that this could also be part of the previous error, since that might be what it does when replication_control.last_replication_date returns something that doesn't look like a date
2013-11-19 32343, 2013
DWSR2
hmm.
2013-11-19 32352, 2013
ianmcorvidae
so, yeah, you need a reimport
2013-11-19 32306, 2013
ianmcorvidae
make sure to set DBDefs back to RT_SLAVE
2013-11-19 32310, 2013
ianmcorvidae
(before reimporting)
2013-11-19 32317, 2013
DWSR2
To go back to a good import, I should DROP DATABASE musicbrainz; CREATE DATABASE musicbrainz; GRANT ALL PRIVILEGES ON DATABASE musicbrainz to musicbrainz; correct?
2013-11-19 32322, 2013
ianmcorvidae
no
2013-11-19 32325, 2013
ianmcorvidae
you should just do the first of those
2013-11-19 32334, 2013
ianmcorvidae
InitDb will create the DB and grant priliveges
2013-11-19 32338, 2013
DWSR2
I tried that and then the import script complained at me.
2013-11-19 32339, 2013
ianmcorvidae
(and create the user)
2013-11-19 32349, 2013
ianmcorvidae
assuming you pass it --createdb, which the instructions should include
2013-11-19 32308, 2013
ianmcorvidae
and I'm assuming you have access to an administrative user on this system and that that's configured properly as SYSTEM in DBDefs
2013-11-19 32319, 2013
ianmcorvidae
(that's the general assumption with our import stuff)
2013-11-19 32344, 2013
JesseW_not_logge joined the channel
2013-11-19 32344, 2013
DWSR2
I'm using whatever the default configuration in the vm is, so I have root access and access to the postgres PSQL user.
2013-11-19 32308, 2013
DWSR2
I should be running the import script as the musicbrainz user, not root, correct?
2013-11-19 32327, 2013
ianmcorvidae
yes, so long as that user has access to the postgres DB role
2013-11-19 32309, 2013
DWSR2
ianmcorvidae: psql: FATAL: database "musicbrainz" does not exist
2013-11-19 32320, 2013
DWSR2
should I remove the user musicbrainz as well?
2013-11-19 32337, 2013
DWSR2
I receive that error when I try using psql as musicbrainz.
2013-11-19 32324, 2013
ianmcorvidae
just straight 'psql' will assume you intend to use the user and database named the same as your system user
2013-11-19 32336, 2013
ianmcorvidae
psql -U <whatever> template1 should always work
2013-11-19 32343, 2013
ianmcorvidae
(assuming the user exists, of course)
2013-11-19 32353, 2013
ianmcorvidae
you don't need to remove the user, anyway, it'll only create that if it doesn't already exist
