Updated several servers here and did not noticed this, maybe its an combination of running services ?It weird. that's why I still not report this issued.
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..Updated several servers here and did not noticed this, maybe its an combination of running services ?
Usually at least 4 to 8 cores, depending.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?
Just tested it under new Reseller and can confirm the same situation on DA 1.672.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
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)
This was the fix, thanks.Thanks for the feedback. We have pushed out an update with the following changes:
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.
- 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.
We have the report to our developers already opened regarding this issue.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)
Just tested it on my test DA 1.672 and can confirm the same small issue there.The 2FA check box to indicate that the device is trusted for 30 days gives an incorrect value of 0 days instead of 30.
You can see the difference here:Hi ;
the new feature
Block browser content sniffing
Added a security feature to block content sniffing by the browsers and trust the Content-Type header sent by the server.
i can't find any Setting for this feature or Setting for enable it ??
how it's works
the was way to add it do we need this ??
[root@ser2 ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/
HTTP/2 200
accept-ranges: bytes
cache-control: no-cache
content-type: text/html; charset=utf-8
cross-origin-resource-policy: same-origin
etag: "137800/173...726/3317"
last-modified: Wed, 18 Dec 2024 07:58:46 GMT
vary: Origin
vary: Accept-Encoding
-----
x-content-type-options: nosniff <------------
-----
x-frame-options: sameorigin
content-length: 3317
date: Sat, 21 Dec 2024 20:12:45 GMT
[root@server2 ~]#
[root@ser ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/
HTTP/2 200
accept-ranges: bytes
cache-control: no-cache
content-type: text/html; charset=utf-8
cross-origin-resource-policy: same-origin
etag: "165400/173...053/3148"
last-modified: Sat, 21 Dec 2024 20:14:13 GMT
vary: Origin
vary: Accept-Encoding
x-frame-options: sameorigin
content-length: 3148
date: Sat, 21 Dec 2024 20:16:03 GMT
[root@ser ~]#
You can see the difference here:
- for DA 1.672:
Bash:[root@ser2 ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/ HTTP/2 200 accept-ranges: bytes cache-control: no-cache content-type: text/html; charset=utf-8 cross-origin-resource-policy: same-origin etag: "137800/173...726/3317" last-modified: Wed, 18 Dec 2024 07:58:46 GMT vary: Origin vary: Accept-Encoding ----- x-content-type-options: nosniff <------------ ----- x-frame-options: sameorigin content-length: 3317 date: Sat, 21 Dec 2024 20:12:45 GMT [root@server2 ~]#
- but for DA version 1.671 or lower version that x-content-type-options: nosniff line is absent:
Bash:[root@ser ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/ HTTP/2 200 accept-ranges: bytes cache-control: no-cache content-type: text/html; charset=utf-8 cross-origin-resource-policy: same-origin etag: "165400/173...053/3148" last-modified: Sat, 21 Dec 2024 20:14:13 GMT vary: Origin vary: Accept-Encoding x-frame-options: sameorigin content-length: 3148 date: Sat, 21 Dec 2024 20:16:03 GMT [root@ser ~]#
Is there a known issue with the latest update (DirectAdmin has been updated to v1.671) that causes directadmin and php-fpm (all sites/instances) to almost non-stop spike CPU and php to run out of memory (which it never did before this update)?
Regrettably updated multiple vps'es, as the first one seemed alright at the time) and all have exactly the same issue and some of these are 1 page (WP/Elementor) websites or even 1 site on a vps only. It seems to affect all different php versions (v7.x and v8.x) installed.
Never had the following issue before the update we did today:
Resource: Virtual Memory Size
Exceeded: 515 > 512 (MB)
Executable: /usr/local/php81/sbin/php-fpm
Command Line: php-fpm: pool
Resource: Virtual Memory Size
Exceeded: 572 > 512 (MB)
Executable: /usr/local/php83/sbin/php-fpm
Command Line: php-fpm: pool
Resource: Virtual Memory Size
Exceeded: 613 > 512 (MB)
Executable: /usr/local/php83/sbin/php-fpm
Command Line: php-fpm: pool
Resource: Virtual Memory Size
Exceeded: 519 > 512 (MB)
Executable: /usr/local/php74/sbin/php-fpm
Command Line: php-fpm: pool
(just added some screenshots to illustrate, but didn't manage to grab the ones with 10+ sites running at > 75% all at the same time)
Please try checking the forum page related to update of DA to version 1.671, starting from this port:We’re experiencing the same issue across 50+ servers. Since the update, we’re getting constant LFD alerts for resource usage, including memory and process count. Servers that haven’t received the DA updates recently are not affected by this problem.
Sure I can disable the LFD reports or thresholds to stop the alerts, but why did these reports started after the updates and what is causing it..