DirectAdmin 1.693

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,291
We are happy to announce the release of DirectAdmin 1.693.

A full release change log is here:

DirectAdmin 1.693


The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
Thank you, but we are still encountering the problem with PHP FPM ISOLATED after the update from MySQL and a restart in this release. Has the update for jailshell to allow the jailed environment to have access to the new MySQL/MariaDB socket if the service was restarted or reinstalled not been implemented? We have also responded to the ticket, where we encounter the error message when we execute
Code:
systemctl restart 'php-isolated-fpm*.service'
We are now encountering this more frequently on other boxes.
Code:
Jan 19 15:18:07 server.com systemd[1]: Failed to start [email protected] - PHP FastCGI Process Manager (for UID 1002).
We did not receive a reply yet.
 
@exlhost, yes this release has the changes to allow jailed environment to have access to MySQL/MariaDB socket even after DB server upgrades or restarts. However, the new jailed environment will only start working after the jailshell script and MySQL/MariaDB server is updated.
 
Invalid MySQL release configured, please change 'mysql' line in options.conf
I know, I know, "You still use 5.7?!", even though it's harmless, is there a way to suppress this message and still be able to upgrade other software?

NB. I can update things within DA, but not via the command line?
NB 2. Can't even update some software, even in DA.

Can I even set it at 8.0 and not upgrade to 8.0?
 
Last edited:
@LawsHosting if you do not want CustomBuild to manage MySQL/MariaDB just set mysql_inst=no in CB options.

Code:
da build set mysql_inst no

This tells CB to stop caring about MySQL/MariaDB installation and leave it up to the system administrator.
 
Hello,

The MySQL and MariaDB server configuration is updated to make sure the UNIX socket for accepting client connections will be created in /run/mysql/mysql.sock. Before this change, the default socket location used to be /var/lib/mysql/mysql.sock.

Users with CloudLinux are highly advised to run the update to DirectAdmin 1.693 controlling how MySQL connection works in cagefs after all. Or keep MySQL socket in /var/lib/mysql/

Found this change breaking CloudLinux servers with MySQL/MariaDB installed by DirectAdmin. The socket /run/mysql/mysql.sock is not available in CloudLinux, and it might break sites:

Steps to test
after upgrading to DirectAdmin 1.693 and performing an upgrade of MySQL/MariaDB:


1. Make sure you have DirectAdmin and MySQL/MariaDB updated, run as root:

Bash:
ls -la /run/mysql/mysql.sock

You should see something like:

Bash:
# ls -la /run/mysql/mysql.sock
srwxrwxrwx 1 mysql mysql 0 Jan 20 09:10 /run/mysql/mysql.sock

Stop here, if the output errors.

2. Connect as any user in CageFS:
Bash:
su - testuser1 -s /bin/bash

3. Run:
Bash:
ls -la /var/lib/mysql/mysql.sock
ls -la /run/mysql/mysql.sock

If you see the error:
Bash:
ls: cannot access '/run/mysql/mysql.sock': No such file or directory

then you need to run the patch offered in the bottom of the post.

example:
Bash:
[testuser1@dev ~]$ ls -la /var/lib/mysql/mysql.sock
lrwxrwxrwx 1 root root 21 Jan 19 17:05 /var/lib/mysql/mysql.sock -> /run/mysql/mysql.sock
[testuser1@dev ~]$ ls -la /run/mysql/mysql.sock
ls: cannot access '/run/mysql/mysql.sock': No such file or directory
[testuser1@dev ~]$

A fix:

The following fix was suggested by Roman from DA team.

Bash:
echo "/run/mysql" >> /etc/cagefs/cagefs.mp
cagefsctl --remount-all

so you can update it to the following view:

Bash:
grep -m1 '^/run/mysql' /etc/cagefs/cagefs.mp || echo "/run/mysql" >> /etc/cagefs/cagefs.mp
cagefsctl --remount-all
 
Last edited:
Just his the MySQL / MariaDB issue myself. Found @zEitEr 's post as I was searching for more information on it. I managed to get around it by changing Drupal / XenForo configs to point to 127.0.0.1 rather than localhost, and bypass the socket initially.
 
Thanks for the feedback. A new DA build is released. It makes sure that on CloudLinux systems the new MySQL/MariaDB socket path will be added to the cagefs configuration file.
 
Never had problems before with any updates but this one has effected my filemanager. When I edit a file the changes are not reflected on a reload or if I go back to inspect the file via an edit. The Green popup tab down the bottom doesn't show its been saved either. I click the save button and no confirmation of it being saved. However if I download the file I can see the changes.

This is a bit frustrating when trying to update code or debug scripts. I then checked the changelog and seen all the updates to filemanager. Definitely not a coincidence as the issues began not long after installing this update.

I have tried the dev tool in browser to see what's being sent or not sent and nothing populates in the network tab. I dissabled cache in the browser..logged out of directadmin and checked file permissions etc.

Please advise.
 
  • Like
Reactions: fln
Thanks for reporting this @TCBOXA. A new build for this DA version is released to make sure File Editor will not use cached data.

Other improvements like notifications are expected to be released with next DA version.
 
I run update all from GUI webpage and mysql.sock still like this "/var/lib/mysql/mysql.sock", manual change to "/run/mysql/mysql.sock" and restart all "php-isolated-*.service". It come back to work as connection "localhost".


~]# cat /etc/my.cnf.d/directadmin-socket.cnf
[client]
socket=/var/lib/mysql/mysql.sock

###Forgot this comment.

Look like it race condition. If "/run/mysql/" directory missing and restart "php-isolated-*.service" before this, the jailshell won't mount dir correctly.

--- re-test again, just reverse the change and restart "mysqld", PHP still connect to database.
This solved for me now.
 
Last edited:
Thanks for reporting this @TCBOXA. A new build for this DA version is released to make sure File Editor will not use cached data.

Other improvements like notifications are expected to be released with next DA version.
Thanks for the hot fix, very much appreciated 👏
 
The new update version 1.693 introduces changes to the Service Monitor manager.

After updating servers to version 1.693, when monitoring via Service Monitor, Dovecot generates a very large number of PIDs.
Meanwhile, on servers running versions earlier than 1.692, Dovecot usually shows only one PID.
Additionally, the number of Dovecot PIDs keeps increasing continuously, and RAM usage becomes very high.
In contrast, PHP-FPM in version 1.693 shows only one PID, whereas in earlier versions, PHP-FPM would spawn multiple PIDs.
Has anyone experienced the same situation as I have?
Could you please share how to handle or resolve this issue?

1.693.png
1.692.png
 
@ViT, latest DA release tracks services in a different way (most of the time more accurately). Information about processes and memory usage are now retrieved from the systemd. This means most of the services are being tracked more accurately. For example, the Dovecot process entry in System services page now includes all dovecot sub-processes (like lmtp, pop3-login, imap-login, ...).

When the PHP-FPM master process starts a pool worker moves out the worker process to a new cgroup slice and systemd starts treating it as external process and no longer includes in the list. That is why it only lists one process now.

Old DA used to go through process list and try to guess which process belongs to which services.
 
  • Like
Reactions: ViT
@fln
May I ask whether the current Dovecot statistics in the new version accurately reflect the services that are actually being used?
After updating, the reported Memory Usage for Dovecot is always much higher than before the update.
Previously, Dovecot typically showed average memory usage of around 300–400 MB. However, it is now reported to have spiked to several times higher, exceeding 2 GB, and this behavior is consistent across all three servers where I upgraded to the new version.
dovecot_1.png
dovecot_2.png
 
We have also reviewed two large boxes with a high number of users, and observe that Dovecot is indeed consuming a significant amount of memory there as well. I am unsure whether this was also the case in the past.
 
Thank you, but we are still encountering the problem with PHP FPM ISOLATED after the update from MySQL and a restart in this release. Has the update for jailshell to allow the jailed environment to have access to the new MySQL/MariaDB socket if the service was restarted or reinstalled not been implemented? We have also responded to the ticket, where we encounter the error message when we execute
Code:
systemctl restart 'php-isolated-fpm*.service'
We are now encountering this more frequently on other boxes.
Code:
Jan 19 15:18:07 server.com systemd[1]: Failed to start [email protected] - PHP FastCGI Process Manager (for UID 1002).
We did not receive a reply yet.
@exlhost - I have the same problem, now still not find what was cause, I create the script to monitor socket at https://forum.directadmin.com/threads/php-fpm-isolated-socket-monitoring.81938/#post-398621 , perhaps you can review and use it.
 
Update to latest DirectAdmin version, After the update to MySQL/MariaDB and jailshell is installed there would be no need to manually restart all the isolated FPM services.
 
Back
Top