Sequel Pro - Socket connection failed - mamp

I use Sequel Pro and MAMP on my Mac to develop wordpress sites locally. This morning when I tried to start up Sequel Pro it kept asking for my password to make changes (it has never done this before). I first tried rebooting my machine but it kept asking so I entered my password to allow (unknown) changes to be made.
Big mistake!
Now when I try to connect via socket I get the error message
Socket connection failed!
Unable to connect via the socket, or the request timed out.
Double-check that the socket path is correct and that you have the necessary privileges, and that the server is running.
MySQL said: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
When I check MAMP the Apache Server light is red, and the MySQL server light is green.
I am a complete novice when it comes to back-end stuff like this, a lot of the answers I have browsed list console commands but I have never used the console before.
I have found a file that is reference in the error - "mysql.sock". This is located in Applications > MAMP > tmp > mysql > mysql.sock
But im not sure what to do with this file (if anything!).
I also found this error log:
130312 11:07:29 mysqld_safe Starting mysqld daemon with databases from /Applications/MAMP/db/mysql
130312 11:07:29 [Warning] You have forced lower_case_table_names to 0 through a command-line option, even though your file system '/Applications/MAMP/db/mysql/' is case insensitive. This means > that you can corrupt a MyISAM table by accessing it with different cases. You should consider changing lower_case_table_names to 1 or 2
130312 11:07:29 [Warning] One can only use the --user switch if running as root
130312 11:07:29 [Note] Plugin 'FEDERATED' is disabled.
130312 11:07:29 [Note] Plugin 'ndbcluster' is disabled.
130312 11:07:29 InnoDB: Started; log sequence number 0 15469736
130312 11:07:30 [Note] Event Scheduler: Loaded 0 events
130312 11:07:30 [Note] /Applications/MAMP/Library/libexec/mysqld: ready for connections.
Version: '5.1.37' socket: '/Applications/MAMP/tmp/mysql/mysql.sock' port: 8889 Source distribution
130312 11:09:37 mysqld_safe A mysqld process already exists
I just dont know what to do with any of the info! Any help is greatly appreciated!

I have the same problem just go and on or start your MAMP and then connect
via socket in Sequel Pro it will work.

Related

Apache Geode can't run with basic instructions

I tried following the basic instructions to run a node over here https://geode.apache.org/docs/guide/114/getting_started/15_minute_quickstart_gfsh.html, but I am getting the following issue:
gfsh>start locator --name=locator1
Starting a Geode Locator in /home/thiago/geode/locator1...
........
Locator in /home/thiago/geode/locator1 on 192.168.50.225[10334] as locator1 is currently online.
Process ID: 28137
Uptime: 5 seconds
Geode Version: 1.14.0
Java Version: 16.0.2
Log File: /home/thiago/geode/locator1/locator1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true -Dgemfire.load-cluster-configuration-from-dir=false -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: /home/thiago/apache-geode-1.14.0/lib/geode-core-1.14.0.jar:/home/thiago/apache-geode-1.14.0/lib/geode-dependencies.jar
Unable to auto-connect (Security Manager may be enabled). Please use "connect --locator=192.168.50.225[10334]" to connect Gfsh to the locator.
Failed to connect; unknown cause: Exception caused JMX Manager startup to fail because: 'java.rmi.server.ExportException: Port already in use: 1099; nested exception is:
java.net.BindException: Failed to create server socket on 127.0.1.1[1099]'
Before starting I made sure nothing was running on port 1099, but after running the command I checked that what uses port 1099 is the spawned java process itself:
❯ lsof -i:1099
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 28137 thiago 206u IPv6 262648 0t0 TCP *:rmiregistry (LISTEN)
Sounds like the issue is because I was using java 16 which does not seems to be supported. Using java 1.8 fixes it.
Same thing still happens with lastest geode and JDK 17. JDK 11 is the latest stable release that will still work
First try downgrading or switching to the stable Java version 1.8 or 11
locator need 10334 port to start and the need 1099 for cluster connection.
To check the port availability:
lsof -I:[port-number]
Then take the PID form the above result to free up the port
To free up the port:
sudo kill PID
if it doesn't work then try
sudo kill -2 PID
or
sudo kill -1 PID
or
sudo kill -9 PID

Armitage 'Connection refused' error in new install of Kali Linux after full upgrade

I installed Kali Linux via VMware and did a full system upgrade:
apt-get update
apt-get upgrade
apt-get full-upgrade
As part of the upgrade postgresql upgraded from v11 to v12. I followed the instructions to finish this part of the upgrade:
pg_dropcluster 12 main --stop
pg_upgradecluster 11 main
pg_dropcluster 11 main
I start postgresql, initialize metasploit, and start Armitage:
/etc/init.d/postgresql start
msfdb init
armitage
The only console output appears unrelated:
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
I do get the popup box with the connection information. I found that I get the "Unexpected end of file from server" if I use 'localhost' as the host, so - per their instructions - I change it to the external IP (in this case 192.168.9.134). I checked metasploit-framework/config/database.yml for
the port and login credentials.
After clicking 'Connect' with this information I get a connection window stating:
Connecting to 192.168.9.134:5432 Connection refused (Connection
refused)
There's also the progress bar that over time will completely fill up (unless I click 'Cancel'). After which nothing happens. As I run the command from the terminal I can see that the process is still running (I don't get my prompt back) but the window disappears and Armitage doesn't actually start. The log file, as verified by pg_lsclusters (/var/log/postgresql/postgresql-12-main.log) doesn't is actually empty.
The link I mentioned before suggests that the problem could either be not enough RAM (I set the VM to have 4gb and free -m shows):
total used free shared buff/cache available
Mem: 3964 803 2677 29 483 2787
Swap: 4093 0 4093
Or that the Metasploit RPC daemon never started (that window does come up the first time, but not subsequent times). I verified that it's running via msfdb status:
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (exited) since Fri 2020-02-07 16:06:52 EST; 19min ago
Process: 1753 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 1753 (code=exited, status=0/SUCCESS)
Feb 07 16:06:52 kali systemd1: Starting PostgreSQL RDBMS... Feb 07
16:06:52 kali systemd1: Started PostgreSQL RDBMS.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME postgres
1735 postgres 3u IPv6 32516 0t0 TCP localhost:5432 (LISTEN)
postgres 1735 postgres 4u IPv4 32517 0t0 TCP localhost:5432
(LISTEN)
UID PID PPID C STIME TTY STAT TIME CMD postgres 1735
1 0 16:06 ? Ss 0:00 /usr/lib/postgresql/12/bin/postgres -D
/var/lib/postgresql/12/main -c
config_file=/etc/postgresql/12/main/postgresql.conf
[+] Detected configuration file
(/usr/share/metasploit-framework/config/database.yml)
Also, running regular Metasploit appears to work fine (msfconsole) and loads without error (not sure if there's any output that would be helpful here). I don't use postgresql directly, so I haven't messed with any configuration nor do I have any other applications (that I'm aware of) that use it, so it should be a pretty clean setup (not to mention this is a fresh install of Kali Linux). I'm out of ideas for what to check next. An online search didn't seem to match this problem well. Any thoughts?
Armitage has been deprecated for some time now, as it has not been updated since 2015, and is (to some extent) incompatible with current versions of metasploit.
Although this may not fix your problem, I suggest not using software this much out of date.

PostgreSQL 10 not able to start on Mac

I'm running PostgreSQL 10 on a mac running macOS Mojave 10.14.1, i'm getting a could not start PostgreSQL server, pg_ctl could not start server.1
and the log shows: 2
-LOG: listening on IPv6 address "::1", port 5432
-LOG: listening on IPv4 address "127.0.0.1", port 5432
-LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
-LOG: database system was interrupted; last known up at 2018-05-28 21:53:17 EDT
-LOG: invalid record length at 0/18B6A00: wanted 24, got 0
-LOG: invalid primary checkpoint record
-LOG: invalid record length at 0/18B6920: wanted 24, got 0
-LOG: invalid secondary checkpoint record
-PANIC: could not locate a valid checkpoint record
-LOG: startup process (PID 3462) was terminated by signal 6: Abort trap
-LOG: aborting startup due to startup process failure
-LOG: database system is shut down
Just wondering if anyone has seen something similar to this.
Thanks
Your database or wal are corrupted. Normally it could fix itself unless it is very bad. Is it a new database? If so, delete it and recreate.

iRODS configuration - Could not start iRODS server during

I've installed postgres as database and then iRODS in Ubuntu 14.04. Then I start its configuration
sudo /var/lib/irods/packaging/setup_irods.sh
After the configuration phase, when iRODS starts the updtating, the first 4 steps go well
Stopping iRODS server...
-----------------------------
Running irods_setup.pl...
Step 1 of 4: Configuring database user...
Updating user's .pgpass...
Skipped. File already uptodate.
Step 2 of 4: Creating database and tables...
Checking whether iCAT database exists...
[mydb] on [localhost] found.
Updating user's .odbc.ini...
Creating iCAT tables...
Skipped. Tables already created.
Testing database communications...
Step 3 of 4: Configuring iRODS server...
Updating /etc/irods/server_config.json...
Updating /etc/irods/database_config.json...
Step 4 of 4: Configuring iRODS user and starting server...
Updating iRODS user's ~/.irods/irods_environment.json...
Starting iRODS server...
but at the end I get this error
Could not start iRODS server.
Starting iRODS server...
Traceback (most recent call last):
File "/var/lib/irods/iRODS/scripts/python/get_db_schema_version.py", line 77, in <module>
current_schema_version = get_current_schema_version(cfg)
File "/var/lib/irods/iRODS/scripts/python/get_db_schema_version.py", line 61, in get_current_schema_version
'get_current_schema_version: failed to find result line for schema_version\n\n{}'.format(format_cmd_result(result)))
RuntimeError: get_current_schema_version: failed to find result line for schema_version
return code: [0]
stdout:
stderr:
ERROR: relation "r_grid_configuration" does not exist
LINE 1: ...option_value from R_GRID_CON...
^
Confirming catalog_schema_version... Success
Validating [/var/lib/irods/.irods/irods_environment.json]... Success
Validating [/etc/irods/server_config.json]... Success
Validating [/etc/irods/hosts_config.json]... Success
Validating [/etc/irods/host_access_control_config.json]... Success
Validating [/etc/irods/database_config.json]... Success
(1) Waiting for process bound to port 5432 ... [-]
(2) Waiting for process bound to port 5432 ... [-]
(4) Waiting for process bound to port 5432 ... [-]
Port 5432 In Use ... Not Starting iRODS Server
Install problem:
Cannot start iRODS server.
Found 0 processes:
There are no iRODS servers running.
Abort.
Have you any ideas on what went wrong?
Because I don't have enough reputation to comment:
Which version of iRODS are you using?
This portion of the output:
Creating iCAT tables...
Skipped. Tables already created.
combined with this portion:
ERROR: relation "r_grid_configuration" does not exist
suggests that the setup ran before, but only partially completed, leaving the system in a broken state. I would recommend reinstallating from scratch, which includes:
Uninstalling the iRODS icat and db plugin packages:
sudo dpkg -P irods-icat irods-database-plugin-postgres
note: make sure to use the -P, so that the configuration files are removed from dpkg's database.
Dropping and remaking the database
Deleting the following directories:
sudo rm -rf /tmp/irods /etc/irods /var/lib/irods
Reinstalling the packages and running sudo /var/lib/irods/packaging/setup_irods.sh
This portion of the output:
(1) Waiting for process bound to port 5432 ... [-]
(2) Waiting for process bound to port 5432 ... [-]
(4) Waiting for process bound to port 5432 ... [-]
Port 5432 In Use ... Not Starting iRODS Server
suggests that you are using port 5432 as your iRODS server port. This will conflict with the default Postgres port. I recommend using the default iRODS server port of 1247. This value was queried during setup as:
iRODS server's port [1247]:
and is recorded in /etc/irods/server_config.json under the zone_port entry.
iRODS-Chat:
It may be easier to continue this on the iRODS-Chat google group. Repairing installs can require back-and-forth communication, which may not be inline with standard stackoverflow usage.

PostgreSQL error: could not receive data from client: An operation was attempted on something that is not a socket

PostgreSQL version 9.1.3. OS is Windows XP. Anti-virus is F-Secure. Six instances of postgres.exe are running.
Here's what's in the pg_log:
2012-04-08 14:58:23 PDT LOG: incomplete startup packet
2012-04-08 14:58:24 PDT LOG: database system is ready to accept connections
2012-04-08 14:58:24 PDT LOG: autovacuum launcher started
2012-04-08 14:58:25 PDT LOG: could not receive data from client: An operation was attempted on something that is not a socket.
2012-04-08 14:58:25 PDT LOG: incomplete startup packet
2012-04-08 14:58:27 PDT LOG: could not receive data from client: An operation was attempted on something that is not a socket.
I disabled F-Secure but it made no difference. Any idea why?
It is not unusual for antivirus products to cause problems even when stopped or disabled. They must sometimes be completely uninstalled to avoid having them get in the way of normal database operations. Another likely possibility is that there is a firewall which needs to be configured to allow the TCP server socket to be opened or the UDP socket used by the various PostgreSQL processes to communicate regarding statistics.