sandbox server not started yet

Hi,
I need more information before suggesting an answer.
Which version of the Sandbox?
Which operating system?

Can you paste here the full command you have used to make the sandbox?

Giuseppe

All commands were executed as "root"

MySQL Sandbox Version : mysql_sandbox_2.0.12

MySQL Binary Version : mysql-5.1.34

mysql_sandbox installation commond : ./make_sandbox mysql-5.1.34.tar.gz

Instances created in : $HOME/sandboxes/msb_5_1_34/

mysql connect command : mysql -u msandbox -p -P 5134 -h aa.bb.cc.dd --socket=/tmp/mysql_sandbox5134.sock

After the install, I wanted to rebooted the server after several days of playing around with mysql 5.1.34 and wanted to start the sandbox and issued the command as
cd $HOME/sandboxes/msb_5_1_34/
./start

The output of the command is :
................... sandbox server not started yet

The file msandbox.err in the folder $HOME/sandboxes/msb_5_1_34/data/msandbox.err is a zero bytes files and does not contain any text.

Hi,

Probably the cause is that you have a ghost instance of the server already running.
You should stop all mysqld and mysqld_safe instances that don't belong to the main server instance (if any), and then reinstall the sandbox using the latest version (see below, #1).

Another possible problem is that you created the sandbox as root and then you try to run it from an unprivileged user. (see below, #2)

A few comments:

1) You are using an old version of MySQL Sandbox. You should use MySQL 3.0.01

2) MySQL Sandbox is not supposed to be run as root. It should be run as unprivileged user. It has not been sufficiently tested as root.

3) Using the Sandbox is much easier if you don't try to connect with the standard MySQL client, but invoke the "./use" script from inside the created Sandbox.

HTH

Giuseppe

I have found this a fairly common error when dealing with external drives or other networked resources. The library, executable, etc. files needed for the sandbox are referenced under paths near where the .tar.gz file was originally unpacked. If this is on an external drive that you have disconnected, you'll get the "sandbox server not started" message with no indication of what required file was missing. If you have moved the .tar.gz and corresponding unpacked directory trees to a different location, you'll need to update paths in several files -- use, start, my, and my.sandbox.cnf.

John,
by design, make_sandbox extracts the tarball in the same location where the tarball file is.
If you are trying a temporary build that you will discard after you use the sandbox, this is fine. If, instead, you wish to keep the expanded tarball for longer, you should move the expanded tarball into $SANDBOX_BINARY, which by default is $HOME/opt/mysql

There is a shortcut to achieve this goal, using make_sandbox with the option --export_binaries

$ mkdir -p $HOME/opt/mysql
$ make_sandbox --export_binaries /external/drive/mysql-5.6.5-linux-x86_64-glibc23.tar.gz

# the binaries will now be in $HOME/opt/mysql/5.6.5 and the sandbox scripts are built with that path

Hi Giuseppe,

My conundrum is that I always start out wanting the unpacked tarball to be permanent. However, I'm running on a Macbook Air with a relatively full internal SSD. So when the MySQL directory tree (or several) begins life on the SSD, I want to move it to an external drive to save on space. Or, if I start with the tarball unpacked on an external drive, I want to disconnect it to carry the laptop outside, so again I'd like to relocate it after the fact.

When I tried to edit the various scripts to reflect the new BASEDIR location, I was successful but I found it required more editing than necessary. For example, in 'use':

export LD_LIBRARY_PATH=/Users/cirrus/sandbox-setup/5.6.6/lib:/Users/cirrus/sandbox-setup/5.6.6/lib/mysql:$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH=/Users/cirrus/sandbox-setup/5.6.6/lib:/Users/cirrus/sandbox-setup/5.6.6/lib/mysql:$DYLD_LIBRARY_PATH
SBDIR="/Users/cirrus/sandboxes/memcached"
# BASEDIR=/volumes/gemini/sandbox-setup/5.6.6
BASEDIR=/Users/cirrus/sandbox-setup/5.6.6

...notice I changed the definition of BASEDIR from /volumes/gemini to /Users/Cirrus, but I had to make the same edit in the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH lines. In the other scripts such as 'start', those *_PATH variables are declared after BASEDIR, and reference $BASEDIR rather than spelling out the full path again.

What seems to happen to me is that after any reboot, some new condition occurs that prompts the 'sandbox server not started' error. I just rebooted a few minutes ago and now on startup it's writing out *.sock files rather than *.pid files, so I'm getting 'sandbox server not started' for what seems like a completely different reason. Just minutes ago, I was happily doing stop, start, use with this particular sandbox, and hadn't made any changes involving ports, protocols, etc.

Anyway, sorry to go off on a tangent. In my experience there are several different / frequent causes for this same 'sandbox server not started' error. I don't know the solution yet for this latest .sock/.pid discrepancy.

John

On May 23, 2012, at 11:45 PM, Giuseppe Maxia wrote:

> Question #72638 on MySQL Sandbox changed:
> https://answers.launchpad.net/mysql-sandbox/+question/72638
>
> Giuseppe Maxia proposed the following answer:
> John,
> by design, make_sandbox extracts the tarball in the same location where the tarball file is.
> If you are trying a temporary build that you will discard after you use the sandbox, this is fine. If, instead, you wish to keep the expanded tarball for longer, you should move the expanded tarball into $SANDBOX_BINARY, which by default is $HOME/opt/mysql
>
> There is a shortcut to achieve this goal, using make_sandbox with the
> option --export_binaries
>
> $ mkdir -p $HOME/opt/mysql
> $ make_sandbox --export_binaries /external/drive/mysql-5.6.5-linux-x86_64-glibc23.tar.gz
>
> # the binaries will now be in $HOME/opt/mysql/5.6.5 and the sandbox
> scripts are built with that path
>
> --
> You received this question notification because you are a direct
> subscriber of the question.

John,
It seems that you are making your life unnecessarily complicated.
Sandbox scripts are not supposed to be changed manually. If you need to do so, use sbtool, which can do that for you without making mistakes.
 sbtool --help
    The MySQL Sandbox, version 3.0.24
    (C) 2006-2010 Giuseppe Maxia
usage: /Users/gmax/usr/local/bin/sbtool [options]
 -o --operation (s) <> - what task to perform
   'info' returns configuration options from a Sandbox
   'plugin' adds plugin support to a sandbox (innodb,semisynch)
   'tree' creates a replication tree
   'move' moves a Sandbox to a different location
   'unpreserve' makes a sandbox NOT permanent
   'range' finds N consecutive ports not yet used by the Sandbox
   'port' Changes a Sandbox port
   'copy' copies data from one Sandbox to another
   'ports' lists ports used by the Sandbox
   'delete' removes a sandbox completely
   'preserve' makes a sandbox permanent

Cheers

Giuseppe

Hi Giuseppe,

What would simplify my life would be a way with sbtool to change the BASEDIR settings in all the scripts for an existing sandbox. Adding --export_binaries to my previous make_sandbox command gives a succession of syntax errors.

I tried adding the --export_binaries option to the command I was already using. Looks like it requires an additional x.y.z version argument, and for the /opt/mysql/<version> directory to already exist. (On OS X, I don't have /opt/mysql at all.) Even after creating /opt/mysql/<version> myself, I could not get the command to run without a syntax error:

$ make_sandbox --export_binaries /volumes/gemini/sandbox-setup/mysql-5.6.6-m9-osx10.6-x86_64.tar.gz --force --sandbox_port=49311 --sandbox_directory=memcached2
...
usage: ./make_sandbox version [options] {VERSION|tarball_full_name}.

# Note: the command above does work if --export_binaries is removed.

$ make_sandbox 5.6.6 --export_binaries /volumes/gemini/sandbox-setup/mysql-5.6.6-m9-osx10.6-x86_64.tar.gz --force --sandbox_port=49311 --sandbox_directory=memcached2
Useless use of /d modifier in transliteration operator at /opt/local/bin/make_sandbox line 269.
Executing low_level_make_sandbox --basedir=/opt/mysql/5.6.6 \
  --sandbox_directory=msb_5_6_6 \
  --install_version=5.6 \
  --sandbox_port=5606 \
  --no_ver_after_name \
  /volumes/gemini/sandbox-setup/mysql-5.6.6-m9-osx10.6-x86_64.tar.gz \
  --force \
  --sandbox_port=49311 \
  --sandbox_directory=memcached2 \
  --my_clause=log-error=msandbox.err
Useless use of /d modifier in transliteration operator at /opt/local/bin/low_level_make_sandbox line 353.
unexpected arguments </volumes/gemini/sandbox-setup/mysql-5.6.6-m9-osx10.6-x86_64.tar.gz>

I notice that it constructed a low_level_make_sandbox command line with 2 --sandbox_port options, the one I specified plus one it derived from the 5.6.6 version number. I don't know if that is the cause of the syntax error, but if I can't get the --export_binaries option working, I have to revert to the previous make_sandbox command that did work.

So I think I must follow the same route as before: install with BASEDIR pointing to my external drive, then update the scripts with BASEDIR pointing to a local directory. I am happy to use sbtool for this last step, but I don't see an option in sbtool though that looks like it will modify BASEDIR in the scripts.

According to low_level_make_sandbox, the default for basedir is /usr/local/mysql:

    -b --basedir = name Base directory for MySQL (default: /usr/local/mysql)

According to the output when I installed, without specifying a --basedir option, basedir points to my external drive:

basedir = /volumes/gemini/sandbox-setup/5.6.6

The sbtool output doesn't mention anything about basedir in its help message:

 -s --source_dir (s) <> - source directory for move, copy, delete
 -d --dest_dir (s) <> - destination directory for move,copy

I don't want to move the sandbox itself, just point BASEDIR to a different location for an existing sandbox. Does one of the sbtool options do that? Is there a way to tell make_sandbox that my tarball is on the external drive but please unpack it to a BASEDIR on the local drive? For space reasons, it's not practical for me to keep both the tarballs and the unpacked x.y.z directories all on the local drive.

Thanks,
John

On May 31, 2012, at 11:15 PM, Giuseppe Maxia wrote:

> Question #72638 on MySQL Sandbox changed:
> https://answers.launchpad.net/mysql-sandbox/+question/72638
>
> Giuseppe Maxia proposed the following answer:
> John,
> It seems that you are making your life unnecessarily complicated.
> Sandbox scripts are not supposed to be changed manually. If you need to do so, use sbtool, which can do that for you without making mistakes.
> sbtool --help
> The MySQL Sandbox, version 3.0.24
> (C) 2006-2010 Giuseppe Maxia
> usage: /Users/gmax/usr/local/bin/sbtool [options]
> -o --operation (s) <> - what task to perform
> 'info' returns configuration options from a Sandbox
> 'plugin' adds plugin support to a sandbox (innodb,semisynch)
> 'tree' creates a replication tree
> 'move' moves a Sandbox to a different location
> 'unpreserve' makes a sandbox NOT permanent
> 'range' finds N consecutive ports not yet used by the Sandbox
> 'port' Changes a Sandbox port
> 'copy' copies data from one Sandbox to another
> 'ports' lists ports used by the Sandbox
> 'delete' removes a sandbox completely
> 'preserve' makes a sandbox permanent
>
>
> Cheers
>
> Giuseppe
>
> --
> You received this question notification because you are a direct
> subscriber of the question.

Hi John,

The reason for the command to fail is because you have already installed the sandbox when you run --export_binaries.
The --export_binaries option is supposed to work only when you install the command for the first time. If you do it twice, it won't work. I understand that it is not the best UI, but this is the way it is for now.

I admit that have never tried installing from a temporary device. I usually rely on networking to acquire my tarballs. Anyway, I have tried, and it is unbearably slow. The reason for the slowness is that the extraction routine has been greatly simplified to the most basic format that can run in most every Unix environment. That said, what happens when you extract is the following:
1) make_sandbox will cd to the directory where the tarball is
2) it will expand the tarball
3) it will rename the inner directory to [optional prefix +] version number
4) if --export_binaries was requested, it will move the new directory to $SANDBOX_BINARY

The best (and quickest) way of installing from a tarball from a temporary device is to copy the tarball to $BINARY_BASE ($HOME/opt/mysql), call make_sandbox (with optional --add_prefix) and then remove the tarball.

Please don't bother with the low_level_make_sandbox defaults. They are supposed to be overwritten by make_sandbox call. I haven't called directly low_level_make_sandbox since I started version 2.0.

Regarding your specific problem, when sbtool works with 'copy' or 'move', it will run a script from inside the sandbox. The script that you need is called 'change_paths' and it was designed to change the path of the sandbox itself. However, you can use it to change the basedir as well

inside the sandbox, you can run:
./stop
mv /Volumes/usbstick/5.5.24 $HOME/opt/mysql/5.5.24 (make sure that the destination directory does not exist!)
./change_paths /Volumes/usbstick/5.5.24 $HOME/opt/mysql/5.5.24
./start

HTH