Hi Marcus, If you configured it as a mono-node then you are correct. However, my understanding (and what the log appears to show) qserv was configured as a clustered system. So, even with one worker you would still need a redirector and the associated cmsd processes. So, the big question is how was this really configured. That would be answered by what is in the qserv-run/etc/lsp.cf configuration file. Andy On Thu, 8 Dec 2016, Marcus Ebert wrote: > Hi Vaikunth, > > Thanks for looking at the logs! > I'm running 1 czar and 1 worker on 1 machine. To start up qserv, I used the > qserv-start.sh script. On a single machine there doesn't need to be a running > cmsd, does it? > > Cheers, > Marcus > > On Wed, 7 Dec 2016, Thukral, Vaikunth wrote: > >> Hi Marcus, >> >> Fritz shared with us the logs you sent and we believe it may be because the >> cmsd service did not start up. To be certain, could you also send us the >> cmsd logs (usually called cmsd.log and cmsd_<date>.log if rolled over) from >> both the czar and the worker instances? Also, what kind of instance are you >> running - 1 czar and 1 worker on 2 separate machines or on 1 machine? >> >> Thanks, >> -Vaikunth >> >>> On Dec 2, 2016, at 11:09 AM, Fritz Mueller <[log in to unmask]> >>> wrote: >>> >>> Hi Marcus, >>> >>> I think the log files would would need to be examined for clues. If you >>> tgz them up shoot them to me in an email, wed happy to take a look? >>> >>> FritzM. >>> >>>> On Dec 2, 2016, at 2:52 AM, Marcus Ebert <[log in to unmask]> wrote: >>>> >>>> Hi, >>>> >>>> We were trying out qserv installations since a while here in Edinburgh >>>> and have now an own database loaded into it (UKIDSS, ~4TB). >>>> That worked fine in the end(we tried so far just a single node >>>> installation to get familar with it and while the other machines for the >>>> test bed gets installed). On the machine where qserv runs, we can connect >>>> as qsmaster using mysql.sock and do queries on the database tables, >>>> including select queries. >>>> >>>> However, connecting through port 4040 shows some problems. We can >>>> connect, list available databases, select the a database, show the tables >>>> and columns of a table, but "select" queries just hang. It's also the >>>> same on the local qserv machine if not going through the socket but >>>> specifiying local host name and port 4040, as well as remotely from >>>> another machine. >>>> >>>> Does anyone kow what else needs to be changed in the qserv configuration >>>> to have this working? I already looked to the grant permissions for >>>> qsmaster, but these seem to be the same when connecting on localhost >>>> through socket and through port 4040. (also changing these for remote >>>> access doesn't change anything) >>>> >>>> >>>> >>>> Cheers, >>>> Marcus >>>> >>>> -- >>>> The University of Edinburgh is a charitable body, registered in >>>> Scotland, with registration number SC005336. >>>> >>>> ######################################################################## >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the QSERV-L list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the QSERV-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >> >> > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1