• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved PHP Warning: unlink(/usr/local/psa/var/modules/watchdog/report/security_2022-01-31): No such file or directory

Visnet

Basic Pleskian
Server operating system version
CentOS 7.9.2009 x86_64
Plesk version and microupdate number
18.0.50.0
Dear Plesk team,

On Jan 29th, I noticed the following cron error:
Code:
PHP Warning:  unlink(/usr/local/psa/var/modules/watchdog/report/security_2022-01-24): No such file or directory in /usr/local/psa/libexec/modules/watchdog/cp/clean-reports on line 11

Today, I received a similar cron error:
Code:
PHP Warning:  unlink(/usr/local/psa/var/modules/watchdog/report/security_2022-01-31): No such file or directory in /usr/local/psa/libexec/modules/watchdog/cp/clean-reports on line 11

I have configured the Watchdog extension to send weekly reports.
The folder with reports looks as follows:
Code:
ll /usr/local/psa/var/modules/watchdog/report/ | tail -n 10
-rw-r-x---. 1 root psaadm   966 Dec 12 01:00 security_2022-12-12
-rw-r-x---. 1 root psaadm   966 Dec 19 01:00 security_2022-12-19
-rw-r-x---. 1 root psaadm   966 Dec 26 01:00 security_2022-12-26
-rw-r-x---. 1 root psaadm   966 Jan  2 01:00 security_2023-01-02
-rw-r-x---. 1 root psaadm   966 Jan  9 01:00 security_2023-01-09
-rw-r-x---. 1 root psaadm   958 Jan 16 01:00 security_2023-01-16
-rw-r-x---. 1 root psaadm   958 Jan 23 01:00 security_2023-01-23
-rw-r-x---. 1 root psaadm   966 Jan 30 01:00 security_2023-01-30
-rw-r-x---. 1 root psaadm   958 Feb  6 01:00 security_2023-02-06
-rw-r-x---. 1 root psaadm 19452 Jun  8  2020 securscan

Not sure why the Watchdog extension wants to remove this file, because 24 Jan and 31 Jan would not be included in the weekly range (23 Jan and 30 Jan are).
I have not changed anything in the Watchdog extension configuration the last few months.

Is this a bug in the Watchdog extension?
 
Dear Plesk team,

On Jan 29th, I noticed the following cron error:
Code:
PHP Warning:  unlink(/usr/local/psa/var/modules/watchdog/report/security_2022-01-24): No such file or directory in /usr/local/psa/libexec/modules/watchdog/cp/clean-reports on line 11

Today, I received a similar cron error:
Code:
PHP Warning:  unlink(/usr/local/psa/var/modules/watchdog/report/security_2022-01-31): No such file or directory in /usr/local/psa/libexec/modules/watchdog/cp/clean-reports on line 11

I have configured the Watchdog extension to send weekly reports.
The folder with reports looks as follows:
Code:
ll /usr/local/psa/var/modules/watchdog/report/ | tail -n 10
-rw-r-x---. 1 root psaadm   966 Dec 12 01:00 security_2022-12-12
-rw-r-x---. 1 root psaadm   966 Dec 19 01:00 security_2022-12-19
-rw-r-x---. 1 root psaadm   966 Dec 26 01:00 security_2022-12-26
-rw-r-x---. 1 root psaadm   966 Jan  2 01:00 security_2023-01-02
-rw-r-x---. 1 root psaadm   966 Jan  9 01:00 security_2023-01-09
-rw-r-x---. 1 root psaadm   958 Jan 16 01:00 security_2023-01-16
-rw-r-x---. 1 root psaadm   958 Jan 23 01:00 security_2023-01-23
-rw-r-x---. 1 root psaadm   966 Jan 30 01:00 security_2023-01-30
-rw-r-x---. 1 root psaadm   958 Feb  6 01:00 security_2023-02-06
-rw-r-x---. 1 root psaadm 19452 Jun  8  2020 securscan

Not sure why the Watchdog extension wants to remove this file, because 24 Jan and 31 Jan would not be included in the weekly range (23 Jan and 30 Jan are).
I have not changed anything in the Watchdog extension configuration the last few months.

Is this a bug in the Watchdog extension?

@Visnet and @Kaspar

Can you check the presence of the file "clean-reports" by running the command :

ll /usr/local/psa/libexec/modules/watchdog/cp/

There should be an executable with the name clean-reports.

If not, then that is the problem.

The root cause might be totally different : the root cause is the reason why the executable was removed.

If you do not have the executable, then it is very likely that it is OS related, not Plesk related - no issues with Ubuntu.

I hope the above helps...

Kind regards....
 
@trialotto, they do -rwxr-x---. 1 root psaadm 674 Jan 15 04:02 clean-reports. Interestingly, your executable seems slightly tinier in file size. Are you running Plesk version .50 as well?
 
No, 18.0.49.2 .......... but Ubuntu based on this particular development server.

Nevertheless, the size of the clean-reports file should not really matter, given the error notification that I have read.

In essence, that error notification is a "humbug" PHP error notification with respect to file renaming.....

..... and I think that you can safely run watchdog without any issues : could you try that?
 
We are noticing this too on all our CentOS 7.9 servers with Plesk version 18.0.49 Update #2. Not sure if Watchdog still works as intended.
 
If you believe you have found a bug, please report it here: Reports
Besides the log entries, do you experience any impact on functionality?
 
We are noticing this too on all our CentOS 7.9 servers with Plesk version 18.0.49 Update #2. Not sure if Watchdog still works as intended.

@RPD and @Kaspar

Please go to the rkhunter directory and run the following command from the command line

./rkhunter -c --configfile /opt/psa/etc/modules/watchdog/rkhunter.conf

and check whether rkhunter still works properly.

It can be the case that you will encounter

a) warnings : most of them can safely be ignored,

b) issues when have customized the rkhunter.conf file : just use a trial-and-error method and comment out the offending config lines.

In essence, if rkhunter works from the command line, then it should also be able to work as a cronjob.

Output is always welcome, if you cannot get rkhunter running!

Kind regards.....

PS @Peter Debik ..... it is probably not a bug at all, watchdog / rkhunter is a bit outdated and does not adapt to new installations (of files/directories etc) and should be reconfigred manually, to my regrets. This is inherent to watchdog / rkhunter, not a bug.
 
@trialotto Thank you for chiming in.

rkhunter is working normally on our servers. We always get weekly reports, so I am sure it works correctly. I don't think the problem is with rkhunter being outdated (it is, I know), but due to a problem with the clean-up routines of watchdog. As the OP mentioned, the problem lies within the file "/usr/local/psa/libexec/modules/watchdog/cp/clean-reports". This file is part of Plesk and it should probably check if a specific report file is present before it tries to delete it. That's the problem. I don't think directory structure has changed in this regard over the past years.
 
Hi,
it checks for the existing files by fetching the filenames from psa.module_watchdog_report table. Technically, those records are removed automatically after the query was run and you've got the warning, so it shouldn't reoccur. However, in case you've restored the psa DB from dump or something you might want to check the DB table <> Filesystem consistency and remove the records which have filenames that do not present in FS.

# plesk db -Ne "select name from module_watchdog_report" | xargs -i ls /usr/local/psa/var/modules/watchdog/report/{} 1>/dev/null

This one could be used to find those.
 
@Peter Debik Thank you for the information. Interestingly, we haven't created any custom logrotate rules nor did we manually delete the corresponding report files. As I already said above, the cleanup routines should be made more robust. A simple check for the existence of the report file would be enough to avoid the warning.
 
@RPD
A simple check for the existence of the report file would be enough to avoid the warning
Yes, that's exactly what is requested within the registered bug. Check should be handled internally to avoid throwing exceptions.
 
No, the reports are not publicly accessible. But fixes are often announced in the change log (which is publicly accessible), so it makes it easier for all to see if an issue has been fixed, if you know the ID. Also, if you have a support request on the same issue, it helps to provide the ID.
 
@Peter Debik Thanks for the explanation. But @Strangelove wrote:

Yes, that's exactly what is requested within the registered bug. Check should be handled internally to avoid throwing exceptions.

So he must have had access to the registered bug. Otherwise he wouldn't know about those details. That's why I was wondering about it. But maybe @Strangelove is the author of the bug report and that's why he knows about its details...
 
Back
Top