Cronjob Type Change Not Applying Until Re-Save

Hi everyone,

I've been performing some tests with cron jobs in ISPConfig, and I've consistently observed what appears to be a bug related to switching between "Full Cron" and "Chrooted Cron" types. It seems that the new cron type setting isn't immediately applied to existing cron jobs until a subsequent modification and save operation is performed on that specific cron job.

Here's the scenario and the steps I've taken:

Initial Setup & Observation (Chrooted Cron -> Full Cron):

I have a cron job configured (let's say it's my Laravel command), initially set to "Chrooted Cron."

In my specific setup, this cron job does not function correctly under "Chrooted Cron" (I'm still investigating the root cause for this, but it's consistent for my tests).

I then change the cron type for the site to "Full Cron" in ISPConfig's settings.

Expectation: The cron job, now under "Full Cron," should start executing correctly (as I know the command works perfectly in a full cron environment).

Actual Result: The cron job continues to fail/not execute, as if it were still configured for "Chrooted Cron."

Workaround: If I then go into the specific cron job's settings (e.g., enable logging, or just toggle the "active" status and save), after this save operation, the cron job starts functioning correctly under "Full Cron."

Inverse Scenario (Full Cron -> Chrooted Cron):

I've observed the exact same behavior in reverse:

I have a cron job configured and working correctly under "Full Cron."

I then change the cron type for the site to "Chrooted Cron."

Expectation: The cron job, now under "Chrooted Cron," should stop functioning (given my initial issues with Jailkit cron).

Actual Result: The cron job continues to function correctly, as if it were still under "Full Cron."

Workaround: If I perform any modification and save on that specific cron job (e.g., activate/deactivate it, or change a setting like logging), after this save, the cron job then stops functioning (as expected under "Chrooted Cron").

Conclusion:

My strong impression is that when the global cron type setting (Full Cron vs. Chrooted Cron) is changed for a site, this change is not immediately or correctly propagated to the cron jobs that are already configured under that site. This happens even though the daemon visibly processes the changes (the red circle disappears and changes appear applied to all domains), implying everything is up-to-date. The propagation only seems to occur when those individual cron jobs are subsequently re-saved.

This seems like a potential bug in how ISPConfig handles the application of the cron type setting to existing cron job definitions. While it could theoretically be related to my specific configuration, my setup is fairly standard, and the consistency of the issue across multiple tests suggests a broader problem.

Has anyone else experienced similar behavior, or could this indeed be a bug that warrants investigation?

Thanks for your time and insights.