DirectAdmin v1.672

it looks like DirectAdmin uses 164.5 CPU in the first image. It may be that DA becomes heavier and also uses more resources. How many cores does the VPS have?
 
Updated several servers here and did not noticed this, maybe its an combination of running services ?
I'm not sure, it report resource usage from the user of my customer. ( And after got report from CSF, pass hourly, CGroup still report high resource usage). I do many thing to resolve this issued.... Like update OS, Reboot Server, ..etc..

Maybe outdate some of linux library ( Only 1-2 month ). Nevermine It still working. 😅
 
it looks like DirectAdmin uses 164.5 CPU in the first image. It may be that DA becomes heavier and also uses more resources. How many cores does the VPS have?
Usually at least 4 to 8 cores, depending.

The thing that gets me most, and why I posted it here that all was well on all those machine and only updating DA (and therefore the custom builds, of course) makes the machines run high.
 
If DA is using a high CPU, run DA in debug mode for 30 minutes or so, and open 2 SSH sessions, one to debug DA and the other for top...... When DA uses a high CPU, switch to the debug session to see what DA is processing........🤷🏻‍♂️
 
The button add user packages if none have been created yet does not work. you can click whatever you want nothing happens.

add.jpg
 
  • Like
Reactions: fln
The button add user packages if none have been created yet does not work. you can click whatever you want nothing happens.

View attachment 8743
Just tested it under new Reseller and can confirm the same situation on DA 1.672.
Downgraded to version 1.671 - it works fine.
I will open internal report to developers to check it closer.
 
I ran into a small issue when installing a new DirectAdmin server, it seems that the symlink for spamd.service is not being created:

OS: Ubuntu 24.04.1 LTS
DA: directadmin current v1.672 f9514c463b99b9d746cf7f35b22a1a05c998b500

Issue has been fixed by creating the symlink manually:

Bash:
root@server:~# systemctl status spamd
Unit spamd.service could not be found.

root@server:/etc/systemd/system# ln -s /etc/systemd/system/spamassassin.service spamd.service

root@server:/etc/systemd/system# systemctl daemon-reload

root@server:/etc/systemd/system# systemctl start spamd

root@server:/etc/systemd/system# systemctl status spamd
● spamassassin.service - Spamassassin daemon
     Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; preset: enabled)
 
Thanks for the feedback. We have pushed out an update with the following changes:
  • Removed the user impersonation bar from File Manager. We expect it to be introduced in the upcoming releases, but it is too early for it in this release. Thanks @JosKlever.
  • Fixed styling of user impersonation bar user selector.
  • Added a temporary workaround for the ConfigServer plugins to continue working without problems. We have reached out to the developers and got confirmation it will be improved from their side as well.
The root cause for the ConfigServer plugins failing to load was a check inside the plugin code that checks for the parent process name. Because of the changes in how plugin processes are started, the name is not the same as before and caused the plugins to stop working. The fix from the plugin side is just to stop checking the name of the parent process. The fix from our side is to continue using the same process name as before.
This was the fix, thanks.
 
I ran into a small issue when installing a new DirectAdmin server, it seems that the symlink for spamd.service is not being created:

OS: Ubuntu 24.04.1 LTS
DA: directadmin current v1.672 f9514c463b99b9d746cf7f35b22a1a05c998b500

Issue has been fixed by creating the symlink manually:

Bash:
root@server:~# systemctl status spamd
Unit spamd.service could not be found.

root@server:/etc/systemd/system# ln -s /etc/systemd/system/spamassassin.service spamd.service

root@server:/etc/systemd/system# systemctl daemon-reload

root@server:/etc/systemd/system# systemctl start spamd

root@server:/etc/systemd/system# systemctl status spamd
● spamassassin.service - Spamassassin daemon
     Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; preset: enabled)
We have the report to our developers already opened regarding this issue.
I opened it several days ago.
Also the problem does not happen only on Ubuntu 24 OS, but I suppose on other OSs too. At least I was able to reproduce it on the server with AlamaLinux 9.X OS.
 
The 2FA check box to indicate that the device is trusted for 30 days gives an incorrect value of 0 days instead of 30.
 
  • Like
Reactions: fln
The 2FA check box to indicate that the device is trusted for 30 days gives an incorrect value of 0 days instead of 30.
Just tested it on my test DA 1.672 and can confirm the same small issue there.
Downgraded to version 1.671 - it works fine.
I opened internal report to developers to get it corrected.
 
Thanks @exlhost. An update is released with the following fixes:
  • Fixed the button to create a new package.
  • Fixed the number of days to remember the 2FA secret on the login page.
  • Fixed a bug in the FileManager tree view. Clicking on a new directory used to expand not the latest visited directory but a previous one.
 
Back
Top