maestro.log and lsp_monitor.log stop rotating on MHO

[JL]

In one site with 2 MHO´s environment running 81.20 take 99, on MHO-A the files maestro.log and lsp_monitor.elg stopped rotating on Jan 6; they grew to ~2.1 GB and more each, while the peer MHO-B rotates normally—no logrotate entries exist for these files, rsyslogd is running, and even after stopping a lingering /opt/CPsuite-R81.20/fw1/bin/syslog -d 515 all debug process and restarting syslog, rotation did not resume.

There are no logrotate rules for these paths and /var/lib/logrotate/status doesn’t exist (same on MHO-B), so rotation appears to be handled by an internal mechanism. MHO-B rotates normally (today’s timestamps). On MHO-A we found an extra process /opt/CPsuite-R81.20/fw1/bin/syslog -d 515 all (debug mode) that did not exist on B; we killed it, truncated the files to recover space, and restarted syslog (rsyslogd), but rotation did not resume. No relevant errors in /var/log/messages.

Looking for guidance on which internal component/service handles rotation for these logs on Maestro, and how to reset or re-enable it without a full reboot.

Regards,

Juan Luis

[AkosBakos]

Hi JL,

I know you are on R81.20 but have a look at on this R81.10 related sk: 

https://support.checkpoint.com/results/sk/sk179712

"Several log files are not rotated in Maestro R81.10 Jumbo Hotfix Take 55 and above, and the size of the files continues to increase. Over time, this could use up the log partition's free space."

Akos

[JL]

Thanks, but that doesn't apply. Besides, I don't need to use the workaround because the start_smo.log file is already in the log_rotation.conf file.

[Expert@MHO-140-A:0]# grep start_smo.log /etc/cpshell/log_rotation.conf
/var/log/start_smo.log 1048576 10
/var/log/start_smo.log.dbg 1048576 10
[Expert@MHO-140-A:0]#

Any ideas?

[Gennady]

Good day!

Would you please check status of "RotateLogs" task in output "cpd_sched_config print"? The task "RotateLogs" calls for "/sbin/cp_logrotate" which in turn takes config from "/etc/cpshell/log_rotation.conf".

"/etc/cpshell/log_rotation.conf" includes maestro.log and lsp_monitor.elg

May it be that the task was somehow stopped or configuration in "/etc/cpshell/log_rotation.conf" was changed?

[JL]

Hi Gennady, thanks for the hint — I checked the RotateLogs scheduler and the configuration.

Findings so far:

1) The “RotateLogs” task is present and active

cpd_sched_config print
Task: "RotateLogs"
    Command: /sbin/cp_logrotate
    Interval: 5
    Active: true
    RunAtStart: true

So the scheduler is running and invoking /sbin/cp_logrotate every 5 minutes.

2) /etc/cpshell/log_rotation.conf is intact
It includes the relevant entries:

/var/log/maestro.log        3145728 10
/var/log/lsp_monitor.elg    3145728 10

and nothing is missing or corrupted.

**3) However, /sbin/cp_logrotate -d produces no output at all on MHO‑A
This is abnormal: the debug mode should list each log file, current size, and rotation actions.
On MHO‑A it returns silently, even though maestro.log and lsp_monitor.elg exceed their size limit.

The same test on MHO‑B behaves normally and logs rotate as expected.

4) Both MHOs use the same binary and same config
md5sum /sbin/cp_logrotate matches between A and B.

5) Root cause
Although both MHOs have the same configuration, it looks like the CPD process on MHO‑A started without the full environment that cp_logrotate expects (particularly variables referenced inside the rotation config).
When the parser encounters an unresolved variable or an invalid path, cp_logrotate aborts silently, without rotating any file.
On MHO‑B the CPD environment is complete, so rotation works.

This explains why:

• RotateLogs is invoked
• log_rotation.conf is correct
• cp_logrotate does nothing
• no errors are generated
• log growth only happens on MHO‑A

Any ideas?,  May be a good option 

cpstop cpd

cpstart cpd

This operation is safe on an MHO, as it does not affect the data plane — only the control-plane daemon is restarted.?

Best regards,

Juan Luis.

[Gennady]

Good day!

I have just tried to restart CPD on MHO under load in a lab. No impact on transit traffic was observed.

Please, note that correct way to stop/start CPD is written in https://support.checkpoint.com/results/sk/sk97638

Stop:

cpwd_admin stop -name CPD -path "$CPDIR/bin/cpd_admin" -command "cpd_admin stop"

Start:

cpwd_admin start -name CPD -path "$CPDIR/bin/cpd" -command "cpd"

[JL]

Hi, thanks.

Your response prompted me to check the status of the cpd process in both orchestrators.

Interestingly, in the one where rotate works, it's running. And in the orchestrator that isn't working, the process is stopped.

[Expert@MHO-140-A:0]# cpwd_admin list | grep cpd
CPD 0 T 0 [10:22:33] 28/1/2026 N cpd
[Expert@MHO-140-A:0]#

[Expert@MHO-140-B:0]#
[Expert@MHO-140-B:0]# cpwd_admin list | grep cpd
CPD 13924 E 1 [01:17:28] 27/5/2025 Y cpd
[Expert@MHO-140-B:0]#

I'm going to start the process as you instructed:

cpwd_admin start -name CPD -path "$CPDIR/bin/cpd" -command "cpd"

And we'll see if rotate works again.

Regards,

[JL]

Simply updating, restarting the cpd process resolved the issue. The cpd process changed to state E, and logrotate started working again.

Regards,