connect(/var/lib/ctdb/ctdb.socket) failed: Connection refused
steve at steve-ss.com
Sun Aug 10 03:13:24 MDT 2014
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.
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
--public_addresses=/usr/local/etc/public_addressess (that as far as
we've got so far!)
The stop command will consist of the elegant:
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
Anyway, keep talking. With the test match finishing early yesterday,
there's precious little left for me to translate today.
More information about the samba-technical