I have MAMP & MAMP PRO. MAMP is working okay, this can successfully start Apache and MySQL and performs normally. MAMP PRO will refuse to start MySQL. I have tried the following setting:
innodb_recovery_force = 1
This was not effective, even when set to level 6. I've tried deleting the two log files contained within the MySQL DB folder. This was also not successful.
I do not care about the databases, I want a fresh clean start. However MAMP PRO refuses to work.
Below is the error log out put:
2017-11-24 20:52:31 10804 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace macs2014_internal/btcontentlocal uses space ID: 358 at filepath: .\macs2014_internal\btcontentlocal.ibd. Cannot open tablespace tripeasi_whitelabel_mobile/authtypeconcretecookiemap which uses space ID: 358 at filepath: .\tripeasi_whitelabel_mobile\authtypeconcretecookiemap.ibd
InnoDB: Error: could not open single-table tablespace file .\tripeasi_whitelabel_mobile\authtypeconcretecookiemap.ibd
I have tried completely reinstalling MAMP multiple times however it still appears to be looking for these databases which no longer exist. As I said before, I do not care about saving data.
Do you have other MySQL processes or Server running at the same time that you are trying to start the MySQL server on MAMP? (this can be checked using te "top" command in terminal)
When I first installed MAMP Pro, MySQL Server (MAMP) could not start, that because a MySQL server was already running. (configured to start automatically with the OS)
If so, you can kill all MySQL processes (don't forget to stop the MAMP servers before) using following command in the terminal: sudo killall -9 mysqld.
An other thing you can try, is:
Quit MAMP
In the finder go to Library/Application Support/appsolute/MAMP PRO/db/mysql56/
Delete the log files
Restart MAMP
I hope that your problem is solved after trying one of those things.
Kind regards,
Dakta
So, the folder on windows located in your public documents for MAMP PRO. This is why none of my settings were working correctly and why these phantom databases were appearing.
I went to:
C:\Users\Public\Documents\Appsolute\MAMPPRO\db
and deleted the databases from there, restarted my server and voila - it works. This is a very confusing place to put the settings for MAMP PRO and I don't really understand why they are there and not where you'd expect them to be in your program files.
Related
this has been annoying me for weeks and i cant find a proper solution.
im running a VPS
centos 7 (and aapanel which has no relevance)
php 7.4
mysql 5.7
phpmyadmin 5.0
ive gone into phpmyadmin, exported a table, updated 5000 rows, and i want to import and overwrite the old data into the same table.
the 'browse' and import is not an option(as vps error 503/low ram to load) and so ive tried to add it by SQL tab:
LOAD DATA LOCAL INFILE '/database/links.csv'
INTO TABLE links
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n';
with permission denied
*yes, ive added
[MySQLi]
mysqli.allow_local_infile = On
to my.conf and even tried to add to php.ini
and restarted apache and even tried removing LOCAL(Saw that on stack too) with no avail*
does anyone have an updated version, or know of a solid solution to this annoying, but should be easy solution?
EDIT
root user = fixes issue for permission denied... but...
LOAD DATA INFILE
error
#1290 - The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
--secure-file-priv has been removed from my.conf and apache restarted and error still appears
LOAD DATA LOCAL INFILE
error
#2000 - LOAD DATA LOCAL INFILE is forbidden, check mysqli.allow_local_infile
mysqli.allow_local_infile = On is still in my.conf
file has full permissions(777) and tried changing owner (www/root/mysql)
Carefully read difference between LOCAL and non-LOCAL versions of LOAD DATA command: https://dev.mysql.com/doc/refman/5.7/en/load-data.html#load-data-local
You need to check state of secure_file_priv config variable for non-LOCAL version of command:
mysql> select ##secure_file_priv;
+-----------------------+
| ##secure_file_priv |
+-----------------------+
| /var/lib/mysql-files/ |
+-----------------------+
File must be located here.
For LOCAL version of the command you must check permission of client to read such file. In case of phpmyadmin it will be php as client.
In both cases double check that mysql server or php both have enough permissions to enter directory and read file. The easiest way is to login under system user for mysql or php and just try to read file:
sudo -u mysql_or_php_user /bin/bash
or
su -s /bin/bash mysql_or_php_user
then
head /database/links.csv
For some reason my production DB decided to spew out this message. All application calls fail to the DB with the error:
PreparedStatementCallback; SQL [ /*long sql statement here*/ ];
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2);
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)
I have no idea, what this even means. There is no file #sql_3c6_0.MYI in /tmp and I can't create one with a # character for some reason. Has anyone heard about it or seen this error? What could be wrong and some possible things to look at?
The MySQL DB seems to be up and running and can be queried via the console but the application can't seem to get through to it. There was no change to the application code/files. It just happened out the blue. So I'm not even sure where to start look or what resolution tactics to apply. Any ideas?
I meet this error too when I run a wordpress on my Fedora system.
I googled it, and find a way to fix this.
Maybe this will help you too.
check mysql config : my.cnf
cat /etc/my.cnf | grep tmpdir
I can't see anything in my my.cnf
add tmpdir=/tmp to my.cnf under [mysqld]
restart web/app and mysql server
/etc/init.d/mysqld restart
Often this means your /tmp partition has run out of space and the file can't be created, or for whatever reason the mysqld process cannot write to that directory because of permission problems. Sometimes this is the case when selinux rains on your parade.
Any operation that requites a "temp file" will go into the /tmp directory by default. The name you're seeing is just some internal random name.
On Fedora with systemd MySQL gets private /tmp directory. In /proc/PID_of_MySQL/mountinfo you will find the line like:
156 129 8:1 /tmp/systemd-namespace-AN7vo9/private /tmp rw,relatime -
ext4 /dev/sda1 rw,seclabel,data=ordered
This means a temporary folder /tmp/systemd-namespace-AN7vo9/private is mounted as /tmp in private namespace of MySQL process. Unfortunately this folder is deleted by tmpwatch if not used frequently.
I modified /etc/cron.daily/tmpwatch and inserted the exclude pattern -X '/tmp/systemd-namespace*' like this:
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X '/tmp/systemd-namespace*' \
-X '/tmp/hsperfdata_*' 10d /tmp
The side effect is that unused private namespace folders will not be deleted automatically.
The filename looks like a temporary table created by a query in MySQL. These files are often very short-lived, they're created during one specific query and cleaned up immediately afterwards.
Yet they can get very large, depending on the amount of data the query needs to process in a temp table. Or you may have multiple concurrent queries creating temp tables, and if enough of these queries run at the same time, they can exhaust disk space.
I do MySQL consulting, and I helped a customer who had intermittent disk full errors on his root partition, even though every time he looked, he had about 6GB free. After we examined his query logs, we discovered that he sometimes had four or more queries running concurrently, each creating a 1.5GB temp table in /tmp, which was on his root partition. Boom!
Solutions I gave him:
Increase the MySQL config variables tmp_table_size and max_heap_table_size so MySQL can create really large temp tables in memory. But it's not a good idea to allow MySQL to create 1.5GB temp tables in memory, because there's no way to limit how many of these are created concurrently. You can exhaust your memory pretty quickly this way.
Set the MySQL config variable tmpdir to a directory on another disk partition with more space.
Figure out which of your queries is creating such big temp tables, and optimize the query. For example, use indexes to help that query reduce its scan to a smaller slice of the table. Or else archive some of the data in the tale so the query doesn't have so many rows to scan.
Tremendous thanks to ArturZ for pointing me in the right direction on this. I don't have tmpwatch installed on my system so that isn't the cause of the problem in my case. But the end result is the same: The private /tmp that systemd creates is getting removed. Here's what happens:
systemd creates a new process via clone() with the CLONE_NEWNS
flag to obtain a private namespace. Or maybe it calls unshare()
with CLONE_NEWNS. Same thing.
systemd creates a subdirectory in /tmp (e.g.
/tmp/systemd-namespace-XRiWad/private) and mounts it on /tmp.
Because CLONE_NEWNS was set in #1, this mountpoint is invisible to
all other processes.
systemd then invokes mysqld in this private namespace.
Some specific database operations (e.g. "describe ;") create
& remove temporary files, which has the side effect of updating the
timestamp on /tmp/systemd-namespace-XRiWad/private. Other database
operations execute without using /tmp at all.
Eventually 10 days go by where even though the database itself
remains active, no operations occur that update the timestamp on
/tmp/systemd-namespace-XRiWad/private.
/bin/systemd-tmpfiles comes along and removes the "old"
/tmp/systemd-namespace-XRiWad/private directory, effectively
rendering the private /tmp unusable for mysqld while the public /tmp
remains available for everything else on the system.
Restarting mysqld works because this starts everything over again at step #1, with a brand new private /tmp directory. However, the problem eventually comes back again. And again.
The simple solution is to configure /bin/systemd-tmpfiles so that it preserves anything in /tmp with the name /tmp/systemd-namespace-*. I did this by creating /etc/tmpfiles.d/privatetmp.conf with the following contents:
x /tmp/systemd-namespace-*
x /tmp/systemd-namespace-*/private
Problem solved.
For me this issue came after a long period of not using mysql nor the webserver. So I was sure that my settings where correct; Simply restarting the service fixes this issue; The weird part about the issue is that one can still connect to the database, and even query/add tables using the mysql tool. for example :
mysql -u root -p
I restarted using :
systemctl start mysqld.service
or
service mysqld restart
or
/etc/init.d/mysqld restart
Note : depending on the machine/environment on of these commands should restart the service.
A better way worked for me.
chown root:root /tmp
chmod 1777 /tmp
/etc/init.d/mysqld restart
That is it.
See here :http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html
http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/
it's very easy, you just grant the /tmp folder as 777 permission.
just type:
chmod -R 777 /tmp
On an Ubuntu box, I started getting this error after moving /tmp to a different volume (symlink). Even after setting the required permission 1777, the issue was not resolved.
MySQL is protected by AppArmor, which was disallowing writes to the new tmp location /mnt/tmp.
I had to add the following lines to /etc/apparmor.d/abstractions/user-tmp to fix this
owner /mnt/tmp/** rwkl,
/mnt/tmp/ rw,
On debian 7.5 I got the same error. I realized the /tmp folder owner and permissions were off. As another answer suggested I did as follows (must be root):
chown root:root /tmp && chmod 1777 /tmp
I did not even have to restart mysql daemon.
I'm using mariadb. When I try to put this line at /etc/my.cnf:
[mysqld]
tmpdir=/tmp
It solved the error generated from website frontend related to /tmp.
But, it has backend problem with /tmp. Example, when I try to rebuild mariadb from the backend, it couldn't read the /tmp dir, and then generated the similar error.
mysqldump: Couldn't execute 'show fields from `wp_autoupdate`': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)
So this one work for both front end and back end:
1. mkdir /var/lib/mysql/tmp
2. chown mysql:mysql /var/lib/mysql/tmp
3. Add the following line into the [mysqld] section:
tmpdir = /var/lib/mysql/tmp
4. Restart mysqld (eg. Centos7: systemctl restart mysqld)
Its due to access control security policies specifically when SELinux is enabled it won't allow external executables to create temporary files in the system locations.
Disable SELinux by issuing below command:
echo 0 >/selinux/enforce
You can now start mysql it wont give any permission related errror while reading/writing to /tmp or system directories.
In case you wish to enable the SELinux security back change 0 to 1 in above command.
Check permission issues, mysql config.
Also check if you haven't reached disk space, quota limits.
Note: Some systems are limiting number of files (not just space), deleting some old session files helped fixed the issue in my case.
For those using VPS / virtual hosting.
I was using a VPS, getting errors with MySQL not being able to write to /tmp, and everything looked correct.
I had enough free space, enough free inodes, correct permissions. Turned out the problem was outside my VPS, it was the machine hosting the VPS that was full. I only had "virtual space" in my file system, but the machine in the background which hosted the VPS had no "physical space" left. I had to contact the VPS company any they fixed it.
If you think this might be your problem, you could test writing a larger file to /tmp (1GB):
dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576
I got a No space left on device error message, which was a giveaway that it was a disk/volume in the background that was full.
I had the same issue and it was caused because our DB server run out of space. Clearing up some disk space solved the issue.
I am new to WordPress, and I am trying to setup it at my local machine.
I am getting error like "Error establishing a database connection".
I tried all solutions from WP blogs,
created new user with all privileges
tired with root user.
created and deleted the target database multiple times.
Nothing is working.
Does anyone know anything else I can try?
Error establishing a database connection doesn't get any simpler than that. Your password, database name, user name, or host is wrong. See http://codex.wordpress.org/Common_WordPress_Errors#Error_Establishing_Database_Connection
Are you sure about using localhost as the server? Are you using MAMP or WAMP?
Try using Adminer http://www.adminer.org/ on your PC/Mac to find the database name, etc., and to admin the database when needed.
If you know can use a shell, try logging into the MySQL server and trying
mysql> show databases;
to list all databases to check your database name.
And try
mysql> mysqlserverinfo --server=root:pass#localhost -d --format=vertical
to get port info, etc. See http://dev.mysql.com/doc/mysql-utilities/1.6/en/mysqlserverinfo.html
I used MAMP for the MySQL server, and used its phpMyAdmin interface to create the database for WordPress and specify its user and password.
Host, for the new database, was "%" on the "User" tab of phpMyAdmin, which it said was supposed to allow any value, and did let me get a certain way through the process. But, I ended up going into "Login Information" under the "User" tab in phpMyAdmin, and changing "%" to "localhost".
That allowed me to finish setting up WordPress.
For future readers, if you are on OSX Yosemite (possibly other versions of OSX as well) and get "Error establishing a database connection" with a local WordPress installation, you may need to do the following:
sudo mkdir /var/mysql
sudo chmod 755 /var/mysql
sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock
Yosemite looks in the wrong location for the mysql.sock file, so creating this symlink to the correct location solves the problem.
The reason the missing symlink is a problem for WordPress specifically is because in your wp-config.php file, define('DB_HOST', 'localhost'); will not work. An alternative workaround is to change this value in your wp-config file to define('DB_HOST', '127.0.0.1');.
The OP didn't say what details they changed in their wp-config file to solve the problem (perhaps it was this DB_HOST parameter) so I just thought I'd post this since I wasted a lot of time trying to figure it out!
I tried all these suggestions and still couldn't get it to work. However, I had installed MySQL v8.0.12 and noticed that in the 'Users and Privileges' section, under the user I had set up, the 'Authentication Type' for the password was set to some kind of 'sha2' setting.
After trying 100 different things, I eventually fixed this by uninstalling then re-installing MySQL, and during the re-installation, specifically choosing the option button that refers to maintaining compatibility with previous versions of MySQL.
I think this resulted in my passwords not being automatically hashed, which enabled Wordpress to successfully connect to my MySQL database.
What worked for me:
-I moved the wp-config.php file into another folder
-Refreshed the browser and Wordpress will try to re-install
-choose a language
-A message should say Wordpress is already installed and will take you to the database setup page.
-Enter the same db name, username, password, and host (usually localhost).
-Got to www.yoursite.com/admin and you should be able to log in.
I had this issue and I have searched a lot but no one mentioned a fix like mine!
I checked my disk size and I found that my disk size was 100% used. I tried to clean up some of the files but still there were very large files taking up a lot of space. I kept looking and found that the mysql ./data folder occupied 90% of my disk space. It was the binlog files! Very large files I ended up cleaning them up using the Reset Master method. There is another method PURGE BINARY LOGS which didn't work for me. I had to use Reset Master. Just follow the steps and make sure you have a good backup. Good Luck.
Try this before anything! It fixed my issue.
sudo service mysql restart
I'm having a strange problem with my vagrant setup: changing characters in a file and saving it doesn't reflect the change in the vm. But if I add/remove some characters or add in a few blank links, everything works fine.
I have already checked if I have opcache enabled on my PHP5.5 and "php -i | grep opcache" get any result ... so I imagine it's no.
Already tested too another vagrant (1.7.2) version, same result.
My configuration is :
Windows 7 Pro
Vagrant 1.6.3 with plugin WinNFSd
VirtualBox 4.3.12
Centos6.5 Box
PHP 5.5.19
Apache 2.4.10
PhpStorm 8 (but problem is same with SublimeText 3 and Notepad++)
Here is a video of a test from me for show you the problem :
https://www.dropbox.com/s/k70fiwfw6mopjs7/2015-03-24%2020-47-07.mp4?dl=0
Two weeks I work on this problem, it will make me crazy ...
I already tried Rsync and Samba or default vagrant synch folder but it doesn't meet my needs.
I really appreciate your help guys!
The problem on sublime was atomic_save setting being true. Not sure if there is an equivalent setting for PHPStorm/Notepad++
https://github.com/mitchellh/vagrant/issues/3888
My Problem I am Having:
I load the database page for one of my innoDB databases from within phpMyAdmin and it loads EXTREMELY slow. We're talking like up to 5 minutes of load time. This only happens on the MAIN page, meaning, when you view the database and the left sidebar that shows all the tables shows up.
After that initial load time, each individual table can be clicked on and load almost immediately. But those tables are loaded in an iframe without reloading the left sidebar of database tables which is why they load so quickly.
After that initial load time, each individual table can be opened in a new tab/window immediately, but doing it that way does not include the left sidebar of database tables, which I am sure is the reason they load so quickly.
What I Expect To Be Happening:
I expect to be able to load the main page of my innoDB database from within phpMyAdmin without it taking 5 minutes to load.
What I've tried:
I've had this issue for months and it drives me crazy every day. I've come to live with it actually. I simply load that initial page immediately every day, and go do something else so i don't have to watch it, because it just makes me angry.
I have my timeout set to about 15 minutes, so if I think its been longer than 10 minutes, I will open where it says "localhost" in a different tab, which brings me to the login screen, log back in, and then it brings me to the list of databases, which loads quickly. This is because if I simply load that main page, then log in, it will bring me back to that index page and i'll wait another 5 minutes for it to load. Grr..
OK so, I Googled and Googled and found tons of suggestions about making innoDB not do row counts and stuff like that. I've tried all of them. Nothing is working! :(
I found something called "$cfg['Server']['IgnoreSomeISrows'] = true;" which did not help whatsoever. I don't even know what it did, but it didn't work, so I removed it, but I forgot to remove that part and so I just left it there. No, commenting it out does not help either thank you.
Some Version Info:
OS
CentOS release 6.5 (Final)
Database:
Server: Localhost via UNIX socket
Software: MySQL
Software version: 5.1.71-log - Source distribution
Protocol version: 10
Web Server
Apache/2.2.15 (CentOS)
Database client version: libmysql - 5.1.71
PHP extension: mysqli Documentation
phpMyAdmin
Version information: 3.5.8.2, latest stable version: 4.1.5
Personally I also experience extremely slow with phpmyadmin, when I view in "View" Table. What I did is upgrade the phpmyadmin to the latest version, then my problem is solved. Maybe u can give a try for phpymadmin v4
Thank you Tom Kim for leading me to the answer.
There wasn't enough room in comments so I will elaborate with an additional answer on exactly what I did to solve my issue. I do not know why the yum version of phpMyAdmin was causing me distress.
backup your config file (if you have made one)
remove the yum version(s) of phpMyAdmin (there are 2 different ones)
download the latest version of phpMyAdmin from their website
unzip it and move it into the normal place
replace (or create) the config file
add a virtual host entry for it and make sure to restrict access to you ONLY YOUR IP ADDRESS for security purposes
restart Apache
Have some tequila to celebrate! preferably reposado because it's the best type :) (this part is VERY important)
Here is my answer in bash form:
(I assume you have phpMyAdmin or phpmyadmin already installed and configured... I won't give you a config file, but I'll give you the vhost file, its mostly based on the one from the yum version of phpMyAdmin):
mkdir /tmp/phpMyAdminNew;
cp /usr/share/phpMyAdmin/config.inc.php /tmp/phpMyAdminNew/config.inc.php;
yum remove phpMyAdmin phpmyadmin;
cd /tmp;
wget -O /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages.zip http://sourceforge.net/projects/phpmyadmin/files/phpMyAdmin/4.1.5/phpMyAdmin-4.1.5-all-languages.zip;
unzip -d /tmp/phpMyAdminNew /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages.zip;
mv /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages /usr/share/phpMyAdminNew
cp /tmp/phpMyAdminNew/config.inc.php /usr/share/phpMyAdminNew/config.inc.php
echo -e 'Alias /my_secret_phpmyadmin_portal /usr/share/phpMyAdminNew\n\n<Directory /usr/share/phpMyAdminNew/>\n\t<IfModule mod_authz_core.c>\n\t\t# Apache 2.4\n\t\t<RequireAny>\n\t\t\tRequire ip 127.0.0.1\n\t\t\tRequire ip ::1\n\t\t\t# Require ip xxx.xxx.xxx.xxx\n\t\t</RequireAny>\n\t</IfModule>\n\t<IfModule !mod_authz_core.c>\n\t\t# Apache 2.2\n\t\tOrder Deny,Allow\n\t\tDeny from All\n\t\tAllow from 127.0.0.1\n\t\tAllow from ::1\n\t\t# Allow from xxx.xxx.xxx.xxx\n\t</IfModule>\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/>\n\t<IfModule mod_authz_core.c>\n\t\t# Apache 2.4\n\t\t<RequireAny>\n\t\t\tRequire ip 127.0.0.1\n\t\t\tRequire ip ::1\n\t\t\t# Require ip xxx.xxx.xxx.xxx\n\t\t</RequireAny>\n\t</IfModule>\n\t<IfModule !mod_authz_core.c>\n\t\t# Apache 2.2\n\t\tOrder Deny,Allow\n\t\tDeny from All\n\t\tAllow from 127.0.0.1\n\t\tAllow from ::1\n\t\t# Allow from xxx.xxx.xxx.xxx\n\t</IfModule>\n</Directory>\n\n# These directories do not require access over HTTP - taken from the original\n# phpMyAdmin upstream tarball\n\n<Directory /usr/share/phpMyAdminNew/libraries/>\n\tOrder Deny,Allow\n\tDeny from All\n\tAllow from None\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/lib/>\n\tOrder Deny,Allow\n\tDeny from All\n\tAllow from None\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/frames/>\n\tOrder Deny,Allow\n\tDeny from All\t\nAllow from None\n</Directory>\n\n# This configuration prevents mod_security at phpMyAdmin directories from\n# filtering SQL etc. This may break your mod_security implementation.\n#\n#<IfModule mod_security.c>\n#\t<Directory /usr/share/phpMyAdminNew/>\n#\t\tSecRuleInheritance Off\n#\t</Directory>\n#</IfModule>' > /etc/httpd/conf.d/phpMyAdminNew.conf;
rm -rf /tmp/phpMyAdminNew
service httpd graceful
clear; echo -e '\n\n##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~##\n ###~~~~~~~~~~~~~~~###\n ####~~~~~~~~~~~####\n #####~~~~~~~~#####\n ##################\n ## TEQUILA SHOT ##\n ##################\n\n';