I am running in the same Linux distro two environments: Plasma (former KDE) and i3wm.
I use the same command on both environments: sudo systemctl start mysql.service && sudo mysql -u root -p -h localhost -P 3306, but while on KDE/Plasma I get no error, on i3wm I get a “the name is not activatable” error, and I don’t know how to fix it (here’s a screenshot).
Here’s an extract from MySQL Workbench:
04:32:53 [ERR][SQL Editor Form]: SQL editor could not be connected: The name is not activatable
04:32:53 [ERR][SQL Editor Form]: Your connection attempt failed for user 'root' to the MySQL server at 127.0.0.1:3306:
The name is not activatable
Also, I found out firefox doesn’t connect to 127.0.0.1:3306 either on i3; on Plasma I get something like (“The connection has been restarted. The connection to the server was reset while the page was loading.”).
I find is interesting too, because syncthing can connects through the localhost on i3wm, but mariadbd can’t for some reason:
sudo lsof -n | grep TCP | grep LISTEN
[…]
syncthing 841 31843 syncthing alberto 14u IPv4 11863 0t0 TCP 127.0.0.1:8384 (LISTEN)
mariadbd 2537 mysql 32u IPv4 16382 0t0 TCP *:mysql (LISTEN)
Hi! Thanks for replying!
After logging on i3,
htopshows me that I have a process called/usr/lib/polkit-1/polkitd --no-debug. I checked withpolkit-kde-agentby running/usr/lib/polkit-kde-authentication-agent-1 &. I started MySQL with the same previous command (sudo systemctl start mysql.service && sudo mysql -u root -p -h localhost -P 3306) and checked the databases (SHOW DATABASES;), which worked: it shows the database with its schemas; but when I open Workbench again, it shows the same error message; so, from what you said above, it sounds more like a Workbench DBus issue (although I have no idea about DBus haha)So you executed KDE’s auth agent in a terminal and then ran the mysql service through the same terminal and everything worked? If so, that’s good. I believe the only thing missing to getting SQL Workbench working is by having your authorization agent of choice launched in your i3 .xinitrc file. That way it should initialize any environment variables for your full graphical session rather just for a single terminal.
Hi again! Thanks for replying! I don’t know what do you mean and how to do this, would you like to help me with that?
Traditionally, one using a “from-scratch” Linux install might start in a console TTY and then use the
startxcommand to start X.org and other applications alongside it (including the window manager like i3). This is often done through the .xinitrc file. In your case, it’s likely that you aren’t using such a method, and rather using a display manager (most likely sddm since you are using KDE Plasma) to launch your user session (a bit of an oversight on my part, my bad). When not having some kind of pre-launch file or some other service list to launch everything surrounding your desktop, you might have to rely on your window manager to ensure secondary processes are launched. I do believe sddm can be configured to allow for additional processes to be launched, but I’ll point you in the direction of doing it from i3’s config files as it’s quite simple to do.Within your i3 config file, you can add exec entries into it. Typically exec entries are meant to be used with bindsym to launch things with a keybind, but you can use exec entries on their own line to launch applications when the configuration file is read (on startup). For instance, you could add the line
exec --no-startup-id "/usr/lib/polkit-kde-authentication-agent-1 &"in order to launch KDE’s polkit authentication agent with your i3 instance, at which point applications (like SQL Workbench) should be able to make use of. As usual, changing your i3 config does require restarting your session for changes to take effect.I see!
I included it into the i3 config file (I saw that it was set up to execute gnome-toolkit (which isn’t installed)), but after changing it to KDE’s, it gets initialized when logging in, but it doesn’t seem to affect Workbench
Perhaps it is possible that multiple issues are involved? Looking back at other issues with SQL Workbench causing DBus failures due to missing DBus endpoints could include the fact that SQL Workbench seems to rely on a keyring (be it Gnome Keyring or KDE Wallet). In an issue posted from 2022, SQL Workbench outright fails to connect to DBs in the same manner described if the keyring application isn’t running. It might be worth using KWalletManager to check through your KDE keyring to see if SQL Workbench has been attempting to store and resolve database passwords through your keyring, which won’t be running by default in a plain i3 session.
It worked!! Is there any way to solve this issue without depending on Kwallet? I’ll investigate for lightweight alternatives :)
As the original issues over on MySQL forums suggested, using DBeaver or other similar software rather than SQL Workbench is the best option. You unfortunately seem to be locked into using a keychain solution if you want to use SQL Workbench.