"mysql -V" and "select version()" show different versions - mariadb

First of all, thanks a lot for your time!
I upgraded MariaDB on Ubuntu 18.04 and restarted: sudo systemctl restart mysql.server several times.
When I run command mysql -V it shows:
mysql Ver 15.1 Distrib 10.3.14-MariaDB, for debian-linux-gnu (x86_64)
using readline 5.2
When I run query SELECT VERSION(); it shows:
10.1.38-MariaDB-0ubuntu0.18.04.1
Any help would be appreciated.

The mysql executable you have installed has a different version than the server it connects to.
Make sure you are connecting to the correct server. Sometimes the configuration defaults file points you automatically to a remote server.
Check where the mysql executable is found from using command -v mysql or which mysql. Most of the time the binary is located in /usr/bin/mysql so you might try invoking that directly to see if that helps.

Related

how to resolve "Error: No module named 'airflow.www'" while starting airflow websever

Getting below error while starting Airflow webserver
balajee#Balajees-MacBook-Air.local:~$ airflow webserver -p 8080
[2018-12-03 00:29:37,066] {init.py:51} INFO - Using executor SequentialExecutor
[2018-12-03 00:29:38,776] {models.py:271} INFO - Filling up the DagBag from /Users/balajee/airflow/dags
Running the Gunicorn Server with:
Workers: 4 sync
Host: 0.0.0.0:8080
Timeout: 120
Logfiles: - -
Error: No module named 'airflow.www'
Fixed for me
pip3 uninstall -y gunicorn
pip3 install gunicorn==19.4.0
I got this problem this morning, and I found a strange solution, may it helps you. I think maybe you just need to change the command running directory.
I install airflow basic dependence in my virtualenv directory venv with PyCharm help, and I use PyCharm build-in Terminal tab to directly access my venv, and I use airflow initdb to init sqlite database to store all my logs and ops, then according to the official tutorial I use airflow webserver to start the webserver. But somehow today I use my Mac terminal, and start virtulenv, and start airflow webserver, and I encounter this problem with:
Running the Gunicorn Server with:
Workers: 4 sync
Host: 0.0.0.0:8080
Timeout: 120
Logfiles: - -
=================================================================
Error: No module named 'airflow.www'
[2019-05-26 07:45:27,130] {cli.py:833} ERROR - No response from gunicorn master within 120 seconds
[2019-05-26 07:45:27,130] {cli.py:834} ERROR - Shutting down webserver
And I tried #Evgeniy Sobolev's solution by reinstall gunicorn and nothing changed, but when I still using my PyCharm Terminal, it can still running successfully. I guess maybe it is because the first directory you init your db and running webserver is critical. By default when I use PyCharm Terminal to init db and start webserver is the Project root directory, like:
(venv) root#root:~/GitHub/FakeProject$ airflow webserver
But today I check into venv to start virtualenv, and the root directory changed!
root#root:~/GitHub/FakeProject/SubDir$ source venv/bin/activate
(venv) root#root:~/GitHub/FakeProject/SubDir$ airflow webserver
** Error **
So in this way it encounters Error: No module named 'airflow.www', so I check out the directory, and the webserver running successfully just like PyCharm Terminal:
(venv) root#root:~/GitHub/FakeProject/SubDir$ cd ..
(venv) root#root:~/GitHub/FakeProject$ airflow webserver
** It works **
I thought maybe airflow store some metadata (like setup a PATH, maybe) in the first time init your airflow db, so you can not change your command running directory.
I hope it may help somebody in the future. Just check your directory!
Looks like you have a problem with gunicorn.
Try to execute this two commands:
sudo -H pip3 uninstall -y gunicorn
sudo -H pip3 install gunicorn
It should resolve your problem, cause airflow show you not clear error message related to gunicorn problems
I did this steps for the problem happens:
create a separate virtualenv only for airflow (I use anaconda distribution)
activate this env with conda activate
install airflow: pip install apache-airflow
at this moment the error No module named 'airflow.www' was showed for me
To fix follow this steps:
Look for where is your gunicorn in: whereis gunicorn
gunicorn have to stay only in your virtualenv directory: /home/yourname/anaconda3/envs/airflow_env/bin/gunicorn
If it stay in two directories, let it just in your airflow enviroment. Remove it all from another.
Another way to verify if gunicorn is in another directories is printing your PATH variable: echo $PATH. Look for gunicorn in /home/yourname/.local/bin and another anaconda directories from PATH. Remove all references. Remove gunicorn from conda base env as well: pip uninstall gunicorn.
With this steps, I think your problem will be solved.
I used anaconda distribution, but I think the same process can be done without it. I used airflow 1.10.0 and python 3.6.
If you have defined a custom home directory for airflow other than default one (~/airflow) during the installation:
You need first export the custom path:
export AIRFLOW_HOME=/your/custom/path/airflow
Go to the airflow directory and then Run the webserver
airflow webserver -p 8080
Run scheduler too
airflow scheduler
please check if gunicorn is installed already in server. for me it was installed in /usr/local/bin and it was taking precedence over gunicorn version installed with airflow. uninstall earlier one or fix $PATH variable
I solved this by starting the webserver from the airflow folder itself.
I was previously trying to open the server from the home directory but the required modules could not be found which may be the case here.
Late to the party but could help others who get here.
I got the same issue using latest airflow version 2.5.0
Make sure env variable AIRFLOW_HOME is pointing to right location
Thanks all for sharing
I added sudo and it actually worked just fine.
I got the same error today and a sudo did the trick to me

Airflow installation issue on Windows 7

How to install Airflow on Windows 7? getting below error while installing it using pip install apache-airflow :
---------------------------------------- Command "c:\users\shrgupta5\appdata\local\programs\python\python36-32\python.exe
-u -c "import setuptools, tokenize;__file__='C:\\Users\\SHRGUP~1\\AppData\\Loca l\\Temp\\pip-build-_yptw7sa\\psutil\\setup.py';f=getattr(tokenize, 'open', open) (__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __fi le__, 'exec'))" install
--record C:\Users\SHRGUP~1\AppData\Local\Temp\pip-_cwm0n u7-record\install-record.txt --single-version-externally-managed
--compile" fail ed with error code 1 in C:\Users\SHRGUP~1\AppData\Local\Temp\pip-build-_yptw7sa\ psutil\
I wouldn't bother trying to install Airflow on windows, even after you install it successfully you cannot run the airflow script due to a dependency on the unix-only module pwd
You can run Airflow on Windows by using the Docker setup from puckel https://github.com/puckel/docker-airflow.
Use VirtualBox and Docker Toolbox(legacy) and setup a docker-machine on your Windows computer (docker-machine create -d virtualbox --virtualbox-cpu-count "2" --virtualbox-memory "2048" default)
make sure to fork puckels git repo underneath c:/Users/yourusername/documents otherwise mounting of DAGS won't work
You should now be able to spin up Airflow e.g. by using the celery-executor setup with docker compose -f docker-compose-CeleryExecutor.yml up -d
I have setup a environment where I develop the DAGs on Windows, test them within the dockercontainer and then push the Dockerimage to Linux to production. I have added a more detailed tutorial here.
Airflow cannot be installed on Windows within the standard command prompt.
You need to use bash and afterwards change the config:
How to run Airflow on Windows
Download the source of airflow from pypi:
https://pypi.org/project/airflow/#files
Unzip and edit setup.cfg, then go to the install_requires section and change the version of psutil with the following: 'psutil>=5.4.7',
Finally, run python setup.py install in the source directory

Cloudstack 4.6.0 system vm are stuck in Starting state

I just finished CloudStack 4.6.0 installation in CentOS 7 and system vms are not able to start, they are stuck in the Staring state. Hipervisor is KVM. I did download the system vm template by this:
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /secondary -u http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2 -h kvm -F
Please let me know what other information to provide. Thank you
been through this error and I can understand the stress :)
Just run the following command
sudo yum upgrade
And then restart cloudstack management server.
Hope this helps.

Can't run psql with postgres running as launch daemon

This is the third time I'm setting up Postgres on a new machine (OS X 10.9 this time), and the third time I'm having problems with the connection.
Basically, I'm at the point where I've created a database cluster and can start postgres using:
postgres -D /usr/local/pgsql/data
But I want it to run in the background as a launch daemon, so I
sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql91-server.plist
It seems like the daemon is launched successfully. But when I type psql I get the same old error message I've been dealing with every single time I try to set up Postgres:
psql: could not connect to server: No such file or directory. Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Any ideas on what might be causing this?
The psql you're running is the old version bundled by Apple in Mac OS X and added to the default PATH. Use the one from Homebrew, by fixing your path or entering the path specifically.
Alternately, explicitly connect to the server by overriding the default socket directory:
psql -h /tmp
See also:
this superuser answer
How to modify PATH for Homebrew?
Update:
In this case it looks like the server is genuinely not starting. Check the permissions on the data directory (apparently /usr/local/pgsql/data) and check the Console.app logs for relevant messages from launchd.
Update:
You must fix the permissions so the postgres user (or postgres_, depending on how you installed) has ownership. Check the launchd config file to see what user it runs as, and sudo chown -R postgres /usr/local/pgsql/data to change ownership. Replace postgres with postgres_ if that's what your launchd config says

Multiple postgreSQL Installations on the same system

I have installed two version of postgreSQL on my Windows 7 dev box. Ver. 9.1 (32-bit) and 9.2 (64-bit). During installation I assigned ver. 9.1 port 5432 and ver 9.2 port 5433. However, whenever I run basic commands like createdb.exe from the 9.2\bin directory, the command runs against the wrong port. Regardless of what commands I run, they always default to the port of the first install (5432). The install directories and data directories are in different locations.
If you don't specify a port, the Postgres tools (e.g. psql) default to 5432. Use the -p switch to change the port that the tool should use, e.g.
psql -p 5433 mydb myuser
Or for the createdb command:
createdb -p 5433 the_new_db
Please read the respective chapters in the manual for details.
If you don't want to specify the port number each time, you can set an environment variable that is picked up by the Postgres tools. This is also explained in the manual: http://www.postgresql.org/docs/current/static/libpq-envars.html

Resources