Title: Site Total v3.1 executes apachectl graceful every 300 seconds, causing continuous Apache SIGUSR1 restarts even when websites use Nginx

Hello,

I have identified and fully traced another reproducible issue in aaPanel.

The site_total service continuously executes:

/www/server/apache/bin/apachectl graceful

every 300 seconds, causing Apache to receive SIGUSR1 and perform a graceful restart approximately 288 times per day.

This happens even though the websites on this server are configured to use Nginx, not Apache.

I traced the process chain using Linux Audit (auditd), so the source of these signals is confirmed.

Environment

OS: Ubuntu 24.04.3 LTS
aaPanel: current version after panel update
Apache: 2.4.68
Nginx: installed and used by the hosted websites
OpenLiteSpeed: installed
Site Total:
- Version: 3.1
- Build Time: 2025-12-16 17:30:00
Site Total binary:

/www/server/site_total/site_total

Site Total systemd unit:

[Unit]
Description=Site Total Service
After=network.target

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/www/server/site_total
ExecStart=/www/server/site_total/site_total
Restart=always
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Problem

Apache was repeatedly receiving:

AH00493: SIGUSR1 received. Doing graceful restart

at an exact 5-minute interval.

Example:

[Wed Aug 12 10:19:39.440909 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:24:39.440095 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:29:39.438809 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:34:39.441230 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:39:39.443290 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:44:39.440493 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:49:39.445712 2026] AH00493: SIGUSR1 received. Doing graceful restart
[Wed Aug 12 10:54:39.446056 2026] AH00493: SIGUSR1 received. Doing graceful restart

This is not a cron task.

System cron and systemd timers were checked and no 5-minute Apache reload task exists.

Site Total is the confirmed source

The site_total service was running as:

root  814  1  /www/server/site_total/site_total

Systemd:

● site_total.service - Site Total Service
   Active: active (running)
   Main PID: 814 (site_total)

It was started at:

Aug 12 05:34:35 Started site_total.service

and reported:

Aug 12 05:34:39 The statistics update service has started.

The Apache reload cycle subsequently followed the same xx:xx:39 timing every 300 seconds.

Kernel audit proof

I installed auditd and monitored execution of:

/www/server/apache/bin/apachectl
/www/server/apache/bin/httpd

and delivery of SIGUSR1 to the Apache master PID.

At exactly 10:49:39, Linux Audit captured the complete chain.

Step 1: `site_total` starts apachectl

Audit record:

type=PROCTITLE:
proctitle=/bin/sh /www/server/apache/bin/apachectl graceful

type=CWD:
cwd=/www/server/site_total

type=EXECVE:
a0=/bin/sh
a1=/www/server/apache/bin/apachectl
a2=graceful

type=SYSCALL:
ppid=814
pid=17350
comm=apachectl
exe=/usr/bin/bash

PPID 814 is /www/server/site_total/site_total.

Therefore:

site_total PID 814
    ↓
/www/server/apache/bin/apachectl graceful

Step 2: apachectl starts httpd graceful

Linux Audit then captured:

proctitle=/www/server/apache/bin/httpd -k graceful

cwd=/www/server/site_total

EXECVE:
a0=/www/server/apache/bin/httpd
a1=-k
a2=graceful

ppid=17350
pid=17352
exe=/www/server/apache/bin/httpd

Therefore:

site_total
    ↓
apachectl graceful
    ↓
httpd -k graceful

Step 3: httpd explicitly sends SIGUSR1 to Apache master

Apache master PID at the time was:

Linux Audit captured:

proctitle=/www/server/apache/bin/httpd -k graceful

type=OBJ_PID:
opid=13181
ocomm=httpd

type=SYSCALL:
syscall=kill
success=yes
a0=0x337d
a1=SIGUSR1
ppid=17350
pid=17352
comm=httpd
exe=/www/server/apache/bin/httpd

0x337d is decimal PID 13181.

Therefore the full confirmed chain is:

/www/server/site_total/site_total
            PID 814
               ↓
/www/server/apache/bin/apachectl graceful
               ↓
/www/server/apache/bin/httpd -k graceful
               ↓
kill(13181, SIGUSR1)
               ↓
Apache master
               ↓
AH00493: SIGUSR1 received. Doing graceful restart

This is not an assumption or a correlation. The entire process chain was captured by the Linux kernel audit subsystem.

Additional behavior during Site Total shutdown

I then stopped site_total.

Immediately during shutdown, another Apache graceful restart occurred at:

10:58:34

Linux Audit captured:

proctitle=/bin/sh /www/server/apache/bin/apachectl graceful

cwd=/www/server/site_total

EXECVE:
a0=/bin/sh
a1=/www/server/apache/bin/apachectl
a2=graceful

ppid=814
pid=17977

Again:

PPID 814 = /www/server/site_total/site_total

Therefore site_total also executes an Apache graceful restart when it is stopped.

A/B test

After stopping Site Total:

systemctl stop site_total

status became:

inactive

The last Apache SIGUSR1 occurred at:

10:58:34

At:

11:24:44

there had been no additional SIGUSR1 events for more than 26 minutes.

Before stopping Site Total they occurred every 300 seconds.

Therefore:

Site Total enabled
→ Apache graceful every 300 seconds

Site Total disabled
→ no periodic Apache graceful restarts

This conclusively confirms Site Total as the source.

Site Total installs configuration for both Nginx and Apache

The Site Total installation contains:

/www/server/site_total/scripts/nginx_site.conf
/www/server/site_total/scripts/apache_site.conf
/www/server/site_total/scripts/site_log_format.conf
/www/server/site_total/scripts/apache_log_format.conf

Its installation script installs configuration for both web servers.

Nginx:

NGINX_VHOST_PATH="/www/server/panel/vhost/nginx"

cp -f \
    "${INSTALL_DIR}/scripts/site_log_format.conf" \
    "${NGINX_VHOST_PATH}/0.site_total_log_format.conf"

Apache:

APACHE_CONF_DIR="/www/server/panel/vhost/apache"

cp -f \
    "${INSTALL_DIR}/scripts/apache_log_format.conf" \
    "${APACHE_CONF_DIR}/0.site_total_log_format.conf"

The actual websites on this server are running on Nginx.

Nevertheless, Site Total continuously manages Apache as well.

Why this behavior is problematic

A graceful reload is appropriate when Apache configuration has actually changed.

For example:

Site Total configuration changed
→ update Apache configuration
→ apachectl graceful once

However, continuously executing:

apachectl graceful

every 300 seconds when no configuration change has occurred is not appropriate.

At the current interval this results in approximately:

12 reloads/hour
288 reloads/day
~105,000 reloads/year

for an otherwise stable Apache instance.

Every execution creates a new Apache graceful restart cycle and worker generation transition.

During the same incident Apache logs also contained messages such as:

AH00488: long lost child came home!

and Apache later became unavailable.

I am not claiming that Site Total has been proven to be the direct cause of the final Apache outage, because that specific causal relationship has not yet been established.

However, performing hundreds of unnecessary graceful restarts every day clearly creates avoidable web-server lifecycle churn and should not happen.

Expected behavior

Site Total should:

Collect website statistics without continuously restarting web servers.
Reload a web server only when Site Total actually changes that server's configuration.
Detect which web server is actually used by a website.
Not manage Apache simply because Apache is installed on the machine.
Not reload Apache when the monitored websites are using Nginx.
Provide a way to keep Website Statistics enabled while disabling unnecessary web-server lifecycle management.
Avoid unconditional Apache reload during each internal 300-second statistics cycle.
Avoid an unnecessary Apache graceful reload when stopping Site Total unless Site Total actually removes or changes Apache configuration.

Current workaround

Because statistics are useful, completely removing Site Total is not an acceptable permanent solution.

For now I have temporarily disabled it:

systemctl disable --now site_total

The statistics data itself has not been deleted.

Existing data remains under:

/www/server/site_total/data/

This workaround prevents the continuous Apache graceful restarts but also disables current website statistics collection.

Questions for aaPanel developers

Please clarify:

Why does Site Total execute apachectl graceful every 300 seconds?
What configuration change requires Apache to be reloaded every five minutes?
Why is Apache being managed when the websites are configured to use Nginx?
Is there a supported configuration to keep Website Statistics enabled without allowing Site Total to reload Apache continuously?
Is this behavior intentional in Site Total 3.1, or is it a bug?
Can Site Total be changed to reload a web server only when its generated configuration has actually changed?

If this is intentional behavior, please explain the technical reason that requires Apache worker generations to be replaced every five minutes for website statistics collection.

Reproduction summary

The issue is reproducible with:

1. Start Site Total.
2. Start Apache.
3. Wait 5 minutes.
4. Observe AH00493 SIGUSR1 graceful restart.
5. Continue waiting.
6. Observe the same restart every 300 seconds.
7. Trace execution with auditd.
8. Observe PPID = Site Total PID for apachectl graceful.
9. Stop Site Total.
10. Periodic Apache SIGUSR1 events stop completely.

I can provide the complete auditd records, Apache logs, Site Total installation scripts, systemd unit, and additional diagnostics if required.

Please investigate this behavior in Site Total 3.1.

Environment

Problem

Site Total is the confirmed source

Kernel audit proof

Step 1: site_total starts apachectl

Step 2: apachectl starts httpd graceful

Step 3: httpd explicitly sends SIGUSR1 to Apache master

Additional behavior during Site Total shutdown

A/B test

Site Total installs configuration for both Nginx and Apache

Why this behavior is problematic

Expected behavior

Current workaround

Questions for aaPanel developers

Reproduction summary

Step 1: `site_total` starts apachectl