connect(/var/lib/ctdb/ctdb.socket) failed: Connection refused

[steve]

On Sun, 2014-08-10 at 09:51 +0100, Rowland Penny wrote:
> On 10/08/14 08:48, steve wrote:
> > On Sat, 2014-08-09 at 21:32 +0200, Volker Lendecke wrote:
> >> On Sat, Aug 09, 2014 at 09:09:05PM +0200, steve wrote:
> >>> OK. We'll have a go but we don't hold out much hope. The default build
> >>> seems to have everything hard wired under /usr/local but surprisingly
> >>> the dbs still go to one of /var/lib/ctdb, /var/ctdb
> >>> or /var/lib/lib/ctdb. All three are written to if they exist.
> >>>
> >>> No one seems to know much about this. There too many words like,
> >>> 'probably', 'seems' and 'maybe' for our liking. I'm sure something will
> >>> click soon. Your fruit harvesting method seems as good a bet as any:)
> >>> Open Source documentation at its very best.
> >> ctdbd configures everything via command line arguments.
> >> ctdbd --help and "man ctdbd" should have the truth.
> >> Everything else is script plumbing.
> >>
> >> Volker
> >>
> > OK. That sounds promising. So we don't need:
> >   /etc/init.d/ctdb start
> > nor
> >   systemctl start ctdb
> > nor
> >   /etc/sysconfig/ctdb
> > or even
> >   /etc/default/ctdb
> >
> > It seems too that cli ctdbd does away with /etc/ctdbd too although all
> > ctdb articles mention it. No matter. We're gonna take the 'everything'
> > as in:
> > 'ctdbd configures everything via command line arguments.'
> > literally.
> >
> > Unfortunately, none of the ctdbd defaults is set. man ctdbd(1) still has
> > e.g.
> > '--dbdir=<directory>
> > [...]
> > This directory would usually be /var/ctdb .'
> >
> > We assume that this is why the distros have stepped in big time. It
> > looks as though every option has to be passed on the command line. There
> > are no defaults.
> >
> > Unfortunately too, no man pages are installed from the
> > source ./configure, make make install. It looks like an option from
> > configure. We really could use some default values. I wonder if this man
> > page is current: http://linux.die.net/man/1/ctdbd
> >
> > Anyway, we've about 8 hours of our allocated
> > get-it-working-on-ubuntu-or-bust time left. It's Sunday, and we've only
> > got ac 'till 14:00. . .
> >
> Hi Steve, the problem with going the way that you are proposing, is that 
> you will have to remember the start command and input it every time you 
> start ctdb, also how do you stop or restart ctdb easily. The idea, with 
> init scripts and conf files, is that everything is remembered for you 
> and you just need to remember how to run the init script.
> 
> I would have thought it would be fairly easy to work out any mods that 
> would be required to the init script & conf files from the ubuntu ctdb 
> package, it might be a bit time consuming based on the number of files 
> in the /etc dir in the package, but I personally think that it would be 
> well worth it, if you are going to use ctdb on Ubuntu long term.
> 
> Rowland

Hi Rowland
You are almost certainly correct, but I'm afraid it's democracy over
here. If this works _today_, the start and stop will be brute force and
ignorance in the form of an executable start script containing all the
ctdbd --dbdir=/usr/local/var/lib/ctdb
--public_addresses=/usr/local/etc/public_addressess (that as far as
we've got so far!)
The stop command will consist of the elegant:
killall ctdbd
For now. All sorts of anomalies already. Even though the binaries have
gone in under /usr/local, the event scripts have ended up in distroland
under /etc

Anyway, keep talking. With the test match finishing early yesterday,
there's precious little left for me to translate today.