I cann't get the scheduler run in my ubuntu or debian linux machines. Originally I had db = DAL('sqlite://storage.sqlite') which causes a weird situation where the website becomes unavailable (the browser cannot establish a connection to the server at 127.0.0.1) but when I run the same app without scheduler (without -K appname), and check the app database, it shows that the scheduler task has been running successfully. What is causing connection to the server to break?
Second, I tried using pymysql or mysqldb instead of sqlite. but, I get this error "Error in URI 'pymysql' or database not supported" even without -K myapp option.
Related
I still don't know if the issue is with docker networking, node, or the connection from node to mysql.
But I have a docker that contains express gateway for api management. Every once in a while it starts giving Operation timed out
The error is coming from nodejs but when it happens :
I can't see anything in the logs of the container
Running tcpdump from the server shows a call being made to the docker api but returns a response of 500 (when running correctly i can see after it the call to the port 3306 to connect to the database)
Running tcpdump from inside the docker container returns absolutely nothing (when working correctly I can see the calls)
Calls that don't require a database connection work correctly! but still i can't see their logs in the container nor their calls inside tcpdump
It's as if the server is calling another docker, but i searched all volumes, images, there's no duplicate.
I tried to check the following :
Resources on the same machine
Resources on the database machine
tcpdump with wireshark on both the server and the docker
Add connection pooling to sequelize (In case a connection to the database is causing the block sometimes)
Checking all oauth2 routes in case it's redirecting to localhost server or anything
Literally adding logs everywhere just to see a log when this happens, but in vain
telnet from the server to the localhost with external port and to 172.17.0.2 with internal port -> slight difference when i do it from localhost, after a while i receive a Connection closed by foreign host
I don't know if it's normal for a docker container to hang like this or if an image is not correctly deleted, but things simply worked when I created the container with another name.
There are many errors I have found across the web that deal with MySQL connection errors, but I have found none that address this specific problem that I am having. In short, I have the newest version of the MySQL Server installed (8.0), I have verified it is running in my Services tab, and I can connect to the server via the MySQL client just fine. However, I cannot open a local connection in Workbench.
When I click on the local instance, it hangs until I manually stop it. I then get the aforementioned error
I then went and ran a diagnostic of the server in the MySQL Installer, which reported that everything is working fine (unless I am reading it wrong)
The logs of said diagnostic also report that the server is installed, functional, and running.
I then checked made sure the server was running in Services
After that, I verified that I could connect to the client, and that I could use the database I was working with (info redacted due to it being company property lol)
Additionally, I also made a new connection on Workbench on port 3307 instead of the standard 3306.
When I click on this, I can enter into the connection without getting the "Cannot access a disposed object" error. However, this connection still cannot connect to the server.
I also saw that some people were having success by navigating into C:\Program Files\MySQL\MySQL Server 8.0\bin and running mysqld --install. This appeared to be beneficial, but ended up doing nothing.
Does anyone know how I can fix this without completely uninstalling everything? Everything was working fine yesterday but has suddenly stopped as of this morning.
I have a need to run mysql queries within gulp to check certain fields in a table. I currently connect to a development server via ssh tunnel, which is opened via terminal so that my host is set to 'localhost'.
When I execute a connection attempt, the tunnel crashes with:
channel 4: open failed: connect failed: Connection refused
Then the server process crashes with an out of memory error.
We use node-mysql2 and a ssh tunnel to run GraphQL locally for testing, so I can't think of anything in particular in gulp that would cause what is essentially a race condition almost instantaneously from the time that the gulp command is sent.
Gulp Code:
If anyone has any insights I'd be much obliged.
Fix can be found here, thanks to the mysql2 developer for pointing me in the right direction!
More info on fix here:
https://stackoverflow.com/a/30669454/705115
I am having my application and database hosted in EngineYard. Suddenly my application is down. I am getting this error when I looked into the log
Mysql2::Error: This connection is still waiting for a result, try again once you have the result
I tried to run some read queries from Rails console in Staging. This is working fine. Database queries returns the expected answers.
Also I checked out the Staging branch in local and checked. I could not reproduce the error in my local. So I assume there is no error in the code.
Restarting the App Server worked for me.
Syntax:
ey ssh "/engineyard/bin/app_<appname> restart" -e your_env_name --app-servers
Reference:
Engineyard command line: ey web restart not working
I've inherited an application making use of python & sqlalchemy to interact with a mysql database. When I issue:
mysql_engine = sqlalchemy.create_engine('mysql://uname:pwd#192.168.xx.xx:3306/testdb', connect_args={'use_unicode':True,'charset':'utf8', 'init_command':'SET NAMES UTF8'}, poolclass=NullPool)
, at startup, an exception is thrown:
cmd = unicode("USE testdb")
with mysql_engine.begin() as conn:
conn.execute(cmd)
sqlalchemy.exc.OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '192.168.xx.xx' (101)") None None
However, using IDLE I can do:
>>> import MySQLdb
>>> Con = MySQLdb.Connect(host="192.168.xx.xx", port=3306, user="uname", passwd="pwd", db="testdb")
>>> Cursor = Con.cursor()
>>> sql = "USE testdb"
>>> Cursor.execute(sql)
The application at this point defaults to using an onboard sqlite database. After this I can quite happily switch to the MySQL database using the create_engine statement above. However, on reboot the MySQL database connection will fail again, defaulting to the onboard sqlite db, etc, etc.
Has anyone got any suggestions as to how this could be happening?
Just thought I would update this - the problem still occurs exactly as described above. I've updated the app so that the user can manually connect to the MySQL db by selecting a menu option. This calls the identical code which exceptions when the app is starting, but works just fine once the app is up and running.
The MySQL instance is completely separate from the app and running throughout, so it should be available to receive connections at all times.
I guess the fundamental question i'm grappling with is how can the same connect code work when the app is up and running, but throw an exception when it is starting?
Is there any artifact of SQLAlchemy that can cause it to fail to create usable connections that isn't dependant on the connection parameters or the remote database?
Ahhh, it all seems so obvious now...
The reason for the exception on startup was because the network interface hadn't finished configuring when the application would make its first request to the remote database. (Which is why the same thing would be successful when attempted at a later time).
As communication with the remote database is a prerequisite for the application, I now do something like this:
if grep -Fxq "mysql" /path/to/my/db/config.config
then
while ! ip a | grep inet.*wlan0 ; do sleep 1; echo "waiting for network..."; done;
fi
... in the startup script for my application - ensuring that the network interface has finished configuring before the application can run.
Of course, the application will never run if the interface doesn't configure, so it still needs some finessing to allow it to timeout and default to using a local database...