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
|