Issue Plesk Monitoring generates thousands of localhost requests in httpsd_access_log

[Azurel]

Server operating system version

AlmaLinux 9.8

Plesk version and microupdate number

18.0.80#2

I noticed that /var/log/plesk/httpsd_access_log is filled with thousands of requests generated by the Plesk Monitoring extension, for example:

127.0.0.1 - - [19/Aug/2026:10:54:20 +0200] "POST /modules/monitoring/public/index.php/Sa_....oY/query HTTP/1.1" 200 129 "-" "Go-http-client/1.1" "-"'/modules/monitoring/public/index.php/Sa_....oY/query' '' '/usr/local/psa/admin/htdocs'

The requests are coming from 127.0.0.1, return HTTP 200, and occur at a very high frequency (in this example every ~2 seconds). The log has grown to around 75 MB in than two weeks. Previous archived files of httpsd_access_log are around 300KB.

# ls -lah /var/log/plesk/httpsd_access_log*
-rw-r--r-- 1 root root  75M Aug 19 12:10 /var/log/plesk/httpsd_access_log
-rw-r--r-- 1 root root 289K Jul 31 03:25 /var/log/plesk/httpsd_access_log-20260731.gz
-rw-r--r-- 1 root root 240K Aug  3 03:44 /var/log/plesk/httpsd_access_log-20260803.gz
-rw-r--r-- 1 root root 328K Aug  6 03:05 /var/log/plesk/httpsd_access_log-20260806.gz

I have this questions:

1. Why are these internal Monitoring requests written to the regular httpsd_access_log at all?
2. Is the very high polling frequency (multiple requests every few seconds) expected behavior, and is there a way to reduce it?
3. Why is my httpsd_access_log not logrotating?

 

[Sebahat.hadzhi]

Why are these internal Monitoring requests written to the regular httpsd_access_log at all?

As far as I am aware, this is expected behavior. Monitoring calls go through the same web server, thus, they get recorded in the same log file.

Is the very high polling frequency (multiple requests every few seconds) expected behavior, and is there a way to reduce it?

When you observe that behavior do you/another admin interact with Monitoring in Plesk panel?

Why is my httpsd_access_log not logrotating?

Can you please confirm what's the current logrotate confirmation and do you observe the issue with that particular file only or with other logs as well?

 

[Azurel]

What files would need to change, and where? Which service create httpsd_access_log-2026XXXX.gz?

I see
/var/log/maillog.processed.1.gz was created 18.08.2026
or
/var/www/vhosts/example.com/logs/access_ssl_log.processed.1.gz was created 19.08.2026

What I find strange is that logrotate supposedly hasn't been running since the upgrade from AlmaLinux 8 to 9. Is it different in AlmaLinux 9?

AlmaLinux8to9 was 07 August:

reboot   system boot  5.14.0-611.55.1. Fri Aug  7 08:39 - 06:13 (1+21:34)
shutdown system down  4.18.0-553.153.1 Fri Aug  7 08:30 - 08:39  (00:08)

# journalctl --since "2026-08-05" | grep -i logrotate
Aug 05 03:47:04 example.com run-parts[3741847]: (/etc/cron.daily) starting logrotate
Aug 05 03:47:11 example.com run-parts[3743433]: (/etc/cron.daily) finished logrotate
Aug 06 03:07:02 example.com run-parts[470927]: (/etc/cron.daily) starting logrotate
Aug 06 03:07:03 example.com run-parts[471997]: (/etc/cron.daily) finished logrotate
Aug 07 03:51:03 example.com run-parts[751895]: (/etc/cron.daily) starting logrotate
Aug 07 03:51:04 example.com run-parts[752951]: (/etc/cron.daily) finished logrotate

help this?

ls -la /etc/cron.daily/
total 32
drwxr-xr-x. 2 root root 4096 Aug 10 20:16 .
drwxr-xr-x. 143 root root 12288 Aug 18 09:52 ..
-rwxr-xr-x 1 root root 539 Aug 10 13:36 50plesk-daily
-rwxr-xr-x 1 root root 82 Jan 3 2019 curl-cacert
-rwxr-xr-x 1 root root 131 Jul 29 13:03 dmarc-report
-rwxr-xr-x 1 root root 756 Jul 29 13:03 plesk-rrd-cleaner


rpm -q logrotate
logrotate-3.18.0-12.el9.x86_64


systemctl status logrotate.timer
○ logrotate.timer - Daily rotation of log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● logrotate.service
Docs: man:logrotate(8)
man:logrotate.conf(5)


systemctl cat logrotate.timer
# /usr/lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target


systemctl cat logrotate.service
# /usr/lib/systemd/system/logrotate.service
[Unit]
Description=Rotate log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
RequiresMountsFor=/var/log
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf

# performance options
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

# hardening options
# details: systemd.exec
# no ProtectHome for userdir logs
# no PrivateNetwork for mail deliviery
# no NoNewPrivileges for third party rotate scripts
# no RestrictSUIDSGID for creating setgid directories
LockPersonality=true
MemoryDenyWriteExecute=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=full
RestrictNamespaces=true
RestrictRealtime=true

# /usr/lib/systemd/system/logrotate.service.d/plesk-httpdmng.conf
[Service]
# Allow normal operation of httpdmng in postrotate of /etc/logrotate.d/mod_security and /etc/logrotate.d/httpd
ReadWritePaths=/usr/local/psa/var /etc/sw/

 

[Azurel]

Maybe a part of the puzzle? I investigated the state of crond and logrotate during the AlmaLinux 8 to 9 upgrade.

The installed logrotate package changed from:
AlmaLinux 8: logrotate-3.14.0-4.el8
AlmaLinux 9: logrotate-3.18.0-12.el9

The EL9 logrotate RPM contains the following scriptlets:
# rpm -q --scripts logrotate

preinstall scriptlet (using /bin/sh):
# If /var/lib/logrotate/logrotate.status does not exist, create it and copy
# the /var/lib/logrotate.status in it (if it exists). We have to do that in pre
# script, otherwise the /var/lib/logrotate/logrotate.status would not be there,
# because during the update, it is removed/renamed.
if [ ! -d /var/lib/logrotate/ -a -f /var/lib/logrotate.status ]; then
  mkdir -p /var/lib/logrotate
  cp -a /var/lib/logrotate.status /var/lib/logrotate
fi
postinstall scriptlet (using /bin/sh):

if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
    # Initial installation
    /usr/lib/systemd/systemd-update-helper install-system-units logrotate.{service,timer} || :
fi

# If there is any cron daemon configured, enable the systemd timer to avoid
# breaking the configuration silently when upgrading from 3.14.0-4 or
# earlier versions
preuninstall scriptlet (using /bin/sh):

if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
    # Package removal, not upgrade
    /usr/lib/systemd/systemd-update-helper remove-system-units logrotate.{service,timer} || :
fi

The comment about the cron daemon is especially interesting because the old system had logrotate 3.14 and was upgraded to 3.18. I also found the following in the Leapp archives. Before the actual upgrade, I performed a test run with "leapp preupgrade". The archive in its "leapp-preupgrade.log", crond was still enabled:

2026-08-06 20:49:20.990 DEBUG PID: 672753 leapp.workflow.FactsCollection.scan_systemd_source: crond.service enabled

The next morning I ran the Plesk almalinux8to9 upgrade. The second archive in its "leapp-preupgrade.log", crond was disabled:

2026-08-07 08:22:09.594 DEBUG PID: 24581 leapp.workflow.FactsCollection.scan_systemd_source: crond.service disabled

and check the time in almalinux8to9.log:

2026-08-07 08:21:12,259 - INFO - Do: disable plesk related services

I then found this in the almalinux8to9 source code, in "systemd.py" its disabled crond right before leapp check:

class DisablePleskRelatedServicesDuringUpgrade(action.ActiveAction):

plesk_systemd_services: typing.List[str]
oneshot_services: typing.List[str]

def __init__(self) -> None:
self.name = "disable plesk related services"

# Be cautious when adding the mailman service here. If mailman is not configured, the service will not start.
# The best way to handle mailman is to use the DisableServiceDuringUpgrade action.
plesk_known_systemd_services = [
"crond.service",
"dovecot.service",
"drwebd.service",
"fail2ban.service",
"httpd.service",
"mariadb.service",
"named-chroot.service",
"plesk-ext-monitoring-hcd.service",
"plesk-ssh-terminal.service",
"plesk-task-manager.service",
"plesk-web-socket.service",
"psa.service",
"sw-collectd.service",
"sw-cp-server.service",
"sw-engine.service",
]

This appears to show that almalinux8to9 explicitly disables/stops crond.service during the upgrade. After the upgrade, crond.service was still disabled and not only that, fail2ban.service was disabled too. After almalinux8to9 nothing worked and I have re-installed plesk.

The important question is therefore:

Could the disabling of crond.service by almalinux8to9 cause the EL9 logrotate RPM not to enable logrotate.timer during the 3.14 → 3.18 transition?

If so, this would explain why /etc/logrotate.d/plesk is no longer processed automatically after the AlmaLinux 8 → 9 upgrade. Before the upgrade, this log was rotated normally.

Could you please confirm whether the almalinux8to9 handling of crond.service is expected to result in logrotate.timer remaining disabled, or whether the upgrade process should explicitly enable logrotate.timer after disabling crond?

What is here todo? Only This? systemctl enable --now logrotate.timer

 

[Sebahat.hadzhi]

Thank you for the details. I can see that you already reported the case to our devs on GitHub and I would like to wait for them to check it out and confirm if this is indeed a gap in the dist-upgrade script.

 

[Azurel]

As far as I am aware, this is expected behavior.

It makes it difficult to extract useful information from the log file when 99.99% of the roughly 12,000 lines consist solely of (localhost) monitoring data.