[PATCH] ctdb: add --rundir switch to override CTDB_RUNDIR

Andrew Bartlett abartlet at samba.org
Wed Sep 9 08:54:56 UTC 2015


On Wed, 2015-09-09 at 10:34 +0200, Michael Adam wrote:
> On 2015-09-09 at 18:08 +1000, Martin Schwenke wrote:
> > On Tue, 8 Sep 2015 10:58:54 +0200, Michael Adam <obnox at samba.org>
> > wrote:
> > 
> > > Needed to be able to run ctdb without prior install (e.g. in
> > > selftest).
> > 
> > I can't think of a better way of doing this but it requires a bit
> > more
> > thought.  The --rundir option you're proposing only influences the
> > location of the lock file used in ctdb_tcp_listen_automatic().
> > 
> > The existing tests that use multiple ctdbd's on a single node
> > insist
> > that the --listen option is used to provide the "private" node IP
> > address.  This avoids the "automatic" case.  However, I can see
> > that we
> > would want to test the "automatic" code under socket wrapper, or
> > whatever.
> 
> Thanks for that hint ... I wasn't aware. :-)
> 
> > Other things that currently live in CTDB_RUNDIR are the PID file
> > and
> > the socket.  These don't follow the proposed --rundir option.  This
> > means that we get a bit of confusion.  We already have --pidfile
> > and
> > --socket options.  --socket is only used for testing, like --rundir
> > would be, so we could drop --socket and just have the socket
> > location
> > follow --rundir.  In ctdbd_wrapper, we could still build and export
> > the
> > value of CTDB_SOCKET (based on CTDB_RUNDIR) so that calls to "ctdb"
> > succeed (I've now remembered that this is the 2nd use of
> > CTDB_SOCKET).
> > 
> > The PID file is more problematic.  First of all, the main reason
> > the
> > --pidfile option exists is so that we don't create the PID file by
> > default when testing (and we don't have access to the compile-time
> > CTDB_RUNDIR).  At the moment we load the configuration in the
> > initscript
> > so that we can get (things including) CTDB_PIDFILE.  The initscript
> > uses the PID file to check the status of ctdbd.  We then pass the
> > PID
> > file location to ctdbd_wrapper, which means we only need to
> > "construct"
> > it once and consistency is guaranteed.  However, given that we load
> > configuration in both places (initscript, ctdbd_wrapper), we could
> > build the PID file location from a CTDB_RUNDIR configuration
> > variable
> > in both places.
> > 
> > So, we could push this patch and then make some additional changes
> > to
> > get more consistency...
> 
> Since my patch just changes the only place in the code that used
> CTDB_RUNDIR before to use the value possibly overridden by
> --rundir now, I'd suggest to push it now and make the other
> possible users of rundir (pid, socket) more systematic later.

Remember that waf can define things (like we already do for module
paths, and many other things) to be either build or install time. 
 Would this help your use case?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the samba-technical mailing list