Applicable to:
- Plesk for Linux
Symptoms
- The following notification is received every hour:
CONFIG_TEXT: Message:
/etc/cron.hourly/asl:
Error: ASL has not been configured
run-parts: /etc/cron.hourly/asl exited with return code 1
EMAIL ERROR - 2 - Manual execution of the task results in the same outcome:
# run-parts /etc/cron.hourly/
/etc/cron.hourly/asl:
Error: ASL has not been configured - Executing
aum -cvia SSH results in another error:# aum -c
-------------------------------------------------------------------------------
Errors were encountered:
L CODE SOURCE MESSAGE
- ---- ----------------------------- ------------------------------------------
4 9998 Core::_get_config New key, updating config
2 2 ASLConfig::config_update An error occurred attempting to read file /etc/asl/config
3 9998 Core::_get_config Failed to update configuration
4 9998 Core::app_exit Exiting with error level 3
------------------------------------------------------------------------------- -
/etc/asl/configfile is empty (1 byte size):# ls -l /etc/asl/config
-rw-------. 1 tortix root 1 Aug 31 04:11 /etc/asl/config
Cause
Aum was updated, but was not configured properly, or /etc/asl/config file is empty.
Resolution
Note: in case you have access to the server via SSH, check the solution from the spoiler below first. Restoring the configuration from the backup overall is a faster way in case there is a backup.
At first, try switching ModSecurity Rule Set back and forth. For that:
- Log in to Plesk.
- Navigate to Tools & Settings > Web Application Firewall (ModSecurity) > Settings.
- Temporary select any other Rule Set, for example, OWASP ModSecurity, and click 'Apply'.
- Select Atomic Basic ModSecurity back and click 'Apply'.
Those actions should re-create the empty /etc/asl/config file.
In case it did not help, try restoring /etc/asl/config from the backup.
Click here to reveal additional information. SSH access is required in order to proceed.
- Log in to the server via SSH.
- List all the configs of asl, there should be a previous version of this file listed, for example:
# ls -lt /etc/asl/config*
-rw-------. 1 tortix root 1 Aug 31 04:11 /etc/asl/config
-rw-------. 1 tortix root 13032 Jun 30 10:09 /etc/asl/config.rpmnew
-rw-------. 1 tortix root 13311 Jun 29 06:00 config.##### - Remove empty /etc/asl/config:
# rm -f /etc/asl/config
- Use the most recent backup of the file found on step 2 to restore it:
# cp -a /etc/asl/config.rpmnew /etc/asl/config
- Try to configure aum:
# aum -c
- Verify that the issue is gone by executing the task manually (it may take a while; in case there is no error from the notification right after the start of the command below, then it works):
# run-parts /etc/cron.hourly/
Comments
21 comments
After the command "run-parts /etc/cron.hourly/" nothing happens, it seems stuck.
Hi @info!
It might be possible in case there were an interference with another task that was running from /etc/cron.hourly/. In general, in case there were no errors right after the start of run-parts, just interrupt the process.
That worked. After waiting about 10-15 minutes step 3 finished, and I could proceed to step 4. Thanks!
It worked! :)
I don't understand this page : it says the issue has been resolved on atomic side, if so why os it still hapening? (last alert 2 min ago)
Hi, @Arnaud!
Based on our information, fix should he delivered in scope of the rule set updates, in case the issue is still actual, force the Atomic Basic ModSecurity rule set update by switching it on and off via Tools & Settings > Web Application Firewall.
aum -c gives -bash: aum: command not found
yum remove aum
downloaded aum-4.0.18-36.el7.art.x86_64.rpm package
yum install aum-4.0.18-36.el7.art.x86_64.rpm
run-parts /etc/cron.hourly/
now gives me new error
This Helped
https://support.plesk.com/hc/en-us/articles/115000143534-ModSecurity-failed-to-update-rule-set-modsecurity-ctl-failed-HTTP-Error-403-Forbidden
The error is now back. I followed the steps of enabling/disabling, it didn't fix it this time. Was there a recent update again?
Hi @Victoria!
Thanks for the report. We are checking this right now and will update the article accordingly.
We had this occur again today. 14 VMs. Had to manually run through each machine (as root user) with:
# aum -c
This seemed to do the trick.
Hope this helps.
Hello, @Nathan Walsh!
Thank you very much for the feedback!
I have also updated the article with the resolution in case aum -c is not working fine.
Hi again, @Victoria!
Please, check the article once again and let me know if that helps.
Same problem here (again). Neither, deactivating the Web Application Firewall NOR following all the steps until aum -c are working. I wasn't able to cp -a /etc/asl/config.rpmnew /etc/asl/config because that file does not exist. aum-c output is:
root@login:/etc/asl# aum -c
-------------------------------------------------------------------------------
Errors were encountered:
L CODE SOURCE MESSAGE
- ---- ----------------------------- ------------------------------------------
4 9998 Core::_get_config New key, updating config
2 2 ASLConfig::config_update An error occurred attempting to read file
/etc/asl/config
3 9998 Core::_get_config Failed to update configuration
4 9998 Core::app_exit Exiting with error level 3
-------------------------------------------------------------------------------
VERSION info:
---
First output was:
root@login:/tmp# ls -lt /etc/asl/config*
-rw------- 1 tortix root 1 Aug 31 06:32 /etc/asl/config
Now same situation:
root@login:/etc/asl# run-parts /etc/cron.hourly/
Error: ASL has not been configured
run-parts: /etc/cron.hourly//asl exited with return code 1
Can you make any suggestions?
Hello, @Globalhawk!
I tested it a little bit more and was able to find another workaround: in case /etc/asl/config exists and empty, and there is no backup, navigate to Tools & Settings > Web Application Firewall > Settings, select any other rule set for a moment (for example OWASP ModSecurity), apply it, and then select Atomic Basic ModSecurity back and apply it.
This actions re-created my /etc/asl/config.
Hello everybody!
The article was updated with only Plesk UI solution that should work without any need to access the server via SSH.
Do not hesitate to leave a comment in case it is not working.
Problem is solved after manually recreating the config-file (touch /ets/asl/config) and switching back to Atomic.
Hi all,
Every hour aum -u is started by cron. It immediately takes 100% cpu, never end (serveral days => never) and every hour another aum -u process starts.
I tried a different ruleset, un- and re-installing, installing but not starting, from both Plesk and the command line, and read most of all contributions about the subject in several fora (problems began in 2014, went away for two years, re-entered in 2016, went away and now at 2018 they're back.
I know that the error about 'There is no indication that the signature belongs to the owner' when updating ModSecurity is probably true but I use the basic ruleset.
And apart from that, what is the reason behind starting some process, let that process delete files regardless if an update succeeds, consumes all CPU and waits til some admin has to kill (all) the process(es) and leaving the installation (and httpd/apache) un-intact?
I'm on:
OS Ubuntu 14.04.5 LTS
Product Plesk Onyx
Version 17.8.11 Update #27, last updated on Oct 25, 2018 05:09 PM
The system is up-to-date. Checked on Oct 20, 2018 10:30 PM.
In Plesk: Error: Failed to update the ModSecurity rule set. Details... (clicking on `Details` does nothing and stays away forever)
In Advisor:
ModSecurity is installed and switched on
Fail2ban is installed and switched on
The Advanced Atomicorp rule set is not selected
Output of yesterday's top
top - 20:03:46 up 4 days, 3:39, 1 user, load average: 28.38, 28.69, 28.62
Tasks: 374 total, 30 running, 343 sleeping, 0 stopped, 1 zombie
%Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16406484 total, 7783124 used, 8623360 free, 698556 buffers
KiB Swap: 7999480 total, 0 used, 7999480 free. 5345788 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29469 root 20 0 11048 4 0 R 29.9 0.0 19:23.19 aum
16817 root 20 0 11048 4 0 R 29.5 0.0 207:55.42 aum
21747 root 20 0 11048 4 0 R 29.5 0.0 133:35.61 aum
4849 root 20 0 11048 4 0 R 29.2 0.0 477:09.53 aum
13257 root 20 0 11048 4 0 R 29.2 0.0 289:10.83 aum
14346 root 20 0 11048 4 0 R 29.2 0.0 260:43.22 aum
26977 root 20 0 11048 4 0 R 29.2 0.0 52:12.38 aum
28398 root 20 0 11048 4 0 R 29.2 0.0 651:53.11 aum
29822 root 20 0 11048 4 0 R 29.2 0.0 577:14.79 aum
1638 root 20 0 11048 4 0 R 28.9 0.0 875:06.00 aum
5326 root 20 0 11048 4 0 R 28.9 0.0 695:15.47 aum
5898 root 20 0 11048 4 0 R 28.9 0.0 432:27.56 aum
18198 root 20 0 11048 4 0 R 28.9 0.0 183:07.16 aum
28937 root 20 0 11048 4 0 R 28.9 0.0 994:38.02 aum
6155 root 20 0 11048 4 0 R 28.5 0.0 522:27.41 aum
7959 root 20 0 11048 4 0 R 28.5 0.0 357:21.69 aum
9418 root 20 0 11048 4 0 R 28.5 0.0 324:11.07 aum
27959 root 20 0 11048 4 0 R 28.5 0.0 37:42.10 aum
28671 root 20 0 11048 4 0 R 28.5 0.0 636:26.94 aum
7019 root 20 0 11048 4 0 R 28.2 0.0 393:33.48 aum
15743 root 20 0 11048 4 0 R 28.2 0.0 231:46.61 aum
24228 root 20 0 11048 4 0 R 28.2 0.0 94:25.83 aum
4053 root 20 0 11048 4 0 R 27.9 0.0 757:24.98 aum
19730 root 20 0 11048 4 0 R 27.9 0.0 158:11.23 aum
25378 root 20 0 11048 4 0 R 27.9 0.0 74:13.44 aum
2872 root 20 0 11048 4 0 R 27.5 0.0 818:15.13 aum
23162 root 20 0 11048 4 0 R 27.5 0.0 115:04.31 aum
541 root 20 0 11048 4 0 R 26.5 0.0 923:20.01 aum
Both aum -u and aum -ck leads to `thermal-thrash-the-CPU`:
output ps -ef | grep aum:
UID PID PPID C STIME TTY TIME CMD
root 541 32648 59 Oct25 ? 15:24:16 /var/asl/bin/aum -ck
root 1638 1512 57 Oct25 ? 14:36:03 /var/asl/bin/aum -ck
root 2872 2842 56 Oct25 ? 13:39:10 /var/asl/bin/aum -ck
root 4053 4031 54 Oct25 ? 12:38:21 /var/asl/bin/aum -ck
root 4849 4825 43 01:53 ? 07:58:06 /var/asl/bin/aum -ck
root 5326 5260 52 Oct25 ? 11:36:05 /var/asl/bin/aum -ck
root 5898 5800 42 02:55 ? 07:13:17 /var/asl/bin/aum -ck
root 6155 6090 45 00:55 ? 08:43:22 /var/asl/bin/aum -ck
root 7019 6935 40 03:56 ? 06:34:30 /var/asl/bin/aum -ck
root 7959 7895 39 04:54 ? 05:58:11 /var/asl/bin/aum -ck
root 9418 9168 38 05:53 ? 05:25:08 /var/asl/bin/aum -ck
root 13257 13087 36 07:00 ? 04:50:07 /var/asl/bin/aum -ck
root 14346 14253 35 07:56 ? 04:21:38 /var/asl/bin/aum -ck
root 15743 15583 34 08:59 ? 03:52:36 /var/asl/bin/aum -ck
root 16817 16778 34 09:53 ? 03:28:52 /var/asl/bin/aum -ck
root 18198 18151 33 10:53 ? 03:03:57 /var/asl/bin/aum -ck
root 19730 19585 32 11:55 ? 02:39:06 /var/asl/bin/aum -ck
root 21747 21397 31 13:03 ? 02:14:32 /var/asl/bin/aum -ck
root 23162 22947 31 13:54 ? 01:56:01 /var/asl/bin/aum -ck
root 24228 24170 30 14:54 ? 01:35:22 /var/asl/bin/aum -ck
root 25378 25267 29 15:55 ? 01:15:03 /var/asl/bin/aum -ck
root 26977 26483 29 17:05 ? 00:53:07 /var/asl/bin/aum -ck
root 27959 27919 28 17:53 ? 00:38:37 /var/asl/bin/aum -ck
root 28398 28294 50 Oct25 ? 10:52:49 /var/asl/bin/aum -uf
root 28671 28626 50 Oct25 ? 10:37:17 /var/asl/bin/aum -ck
root 28937 28093 61 Oct25 ? 16:35:32 /var/asl/bin/aum -uf
root 29469 29383 28 18:55 ? 00:20:20 /var/asl/bin/aum -ck
root 29822 29764 47 Oct25 ? 09:38:11 /var/asl/bin/aum -ck
root 31427 30456 24 20:03 ? 00:00:49 /var/asl/bin/aum -ck
root 31531 31400 0 20:07 pts/0 00:00:00 grep --color=auto aum
After killing all `aum` processes, CPU went from 100% to 0.5%
Now details about the update itself:
Error: Failed to update the ModSecurity rule set: modsecurity_ctl failed: gpg: key 4520AFA9: "Atomicorp (Atomicorp Official Signing Key) <support@atomicorp.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: Signature made Wed Oct 24 23:26:39 2018 CEST using RSA key ID 4520AFA9
gpg: Good signature from "Atomicorp (Atomicorp Official Signing Key) <support@atomicorp.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1818 66DF 9DAC A40E 5B42 9B08 FFBD 5D0A 4520 AFA9
TERM environment variable not set.
--2018-10-25 16:56:19-- https://www.atomicorp.com/RPM-GPG-KEY.atomicorp.txt
Resolving www.atomicorp.com (www.atomicorp.com)... 74.208.77.16
Connecting to www.atomicorp.com (www.atomicorp.com)|74.208.77.16|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1694 (1.7K) [text/plain]
Saving to: 'STDOUT'
0K . 100% 364M=0s
2018-10-25 16:56:20 (364 MB/s) - written to stdout [1694/1694]
aum failed with exitcode -15.
stdout:
stderr:
Unable to download tortix rule set
Why keeps the aum-process running while it knows it didn't succeed?
Switched to other rules (since updating fails)
In Plesk, uncheck Atomic ruleset
In Plesk, check OWASP (location: root@xxxxxxxx:/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_3-plesk#)
...AND...
killed (all) aum process(es) because every hour there's a new one.
The config file is NOT empty
ls -lt /etc/asl/config*
-rw------- 1 tortix root 13357 Oct 27 14:43 /etc/asl/config
-rw------- 1 tortix root 13097 Oct 16 00:59 /etc/asl/config.dpkg-dist
Ehhhm, any suggestions?
Kind regards,
Eef
Hello, @Eef Vreeland.
I think the cause might be the same as described in the following article:
https://support.plesk.com/hc/en-us/articles/360006023734-Cannot-activate-ModSecurity-aum-uses-100-CPU-on-Ubuntu-16
I suggest updating the OS to the most recent version including installation of kernel updates to resolve it.
Hi Alexandr,
Hats off, I am glad to inform you that the suggested solution worked. Tomorrow I will check if the rule-update went well but I don't expect any problems.
I think `apt-get install linux-generic` did the actual tric.
Thank for teaching me `Search, and find it .... in front of you` ;-)
Take care,
Eef
I recently change all the email setting to retrieve my email setting back but I am having an error 0x800ccc1a when I try to change its functionality. Firstly I want to solve my id issue then email.
Hello @Martina,
The error you show is Outlook-specific and is usually caused by Outlook misconfiguration.
Make sure that you have selected the correct ports for mail protocols when were setting it up.
In case the instruction does not help, contact Microsoft Support.
Please sign in to leave a comment.