 |
 |
You might be starting both at once, and OS scheduling starts xrootd seconds or a minute before mysqld. I'm in favor of having the worker own its mysqld completely--handling start-stop-config, so it's (almost) impossible to have a missing/inaccessible mysqld. -Daniel On 03/05/2014 10:54 AM, Becla, Jacek wrote: > Daniel > > Even in production, if mysql does not start, continuing > with starting xrootd is pointless (right?). > > I fully agree about trying to recover, retrying and > whatever it takes. > > I'll open a ticket. > > Jacek > > > On 03/05/2014 10:43 AM, Daniel L. Wang wrote: >> The thing is, for now, it should abort. In production, I'm not sure it >> should. At the very least, it should retry for some time. >> >> -Daniel >> (this wouldn't be such a problem if the worker embedded its own mysqld >> or was responsible for starting it) >> >> On 03/05/2014 09:27 AM, Becla, Jacek wrote: >>> Daniel >>> >>> I noticed xrootd will happily start even if it can't connect >>> to mysql. It will only print a message: >>> >>> Configration invalid: Unable to connect to MySQL with config: >>> >>> which can be easily overlooked. I propose to make this a fatal >>> error and abort. Sounds ok? Should I open a ticket? >>> >>> Jacek ######################################################################## 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