Good morning We wanted to ask about the functionality of incron in relation to web hosting that can be created with ispconfig. We've read that it's used to monitor changes in the file system in order to take appropriate action in case of modifications. We have it installed on the servers we've integrated into our ispconfig (CentOS/Alma Linux environments) because we were seeing warning messages in the logs about operations that couldn't be executed due to incron not being installed. The thing is, we see that incron is creating files of this type (for example, for the website identified with ID 97) on the nodes where the website is created (master/web server mirrors) in our environment. #cat /etc/incron.d/web97.conf /datoshostingpre/jails/clients/client7/web97/private/php-fpm.reload IN_CLOSE_WRITE systemctl reload php74-php-fpm.service Where we understand that: a- a file we created within the web hosting is monitored (in our case, (/datoshostingpre/jails/clients/client7/web97/private/php-fpm.reload) b- If a closing event occurs in that file (not open for writing), then c- we would force a reload of the php-fpm version serving that website at that moment. Our question is: what kind of website modifications does this incron configuration generated by ispconfig attempt to monitor? Thank you very much and best regards.
You manually enabled the PHP-FPM incron reload function and what it does is decribed in the incron plugin: Code: /** * If your websites use PHP-FPM and you have incron installed, you can use this plugin to automatically add incron * configuration which will take care of reloading the php-fpm pool when the file /private/php-fpm.reload is touched. * Projects which use deployment tools can use this to reload php-fpm to clear the opcache at deploy time, without * requiring superuser privileges. * * The plugin is prefixed with `z_` because plugins are executed alphabetically, and this plugin * must only run after apache2/nginx plugins so we are sure the directories and user/group exist. */ class
As systemd has matured, its own built-in path units are now the standard method for monitoring filesystem events and triggering actions, largely phasing out incron. The core of this transition is that systemd.path unit files leverage the same Linux kernel inotify subsystem as incron, but integrate the functionality directly into the systemd ecosystem which is much preferred, moving forward to the future. That quoted, if you did manually use incron, to monitor things in your new servers, as suggested above, you should migrate all incron setup to systemd whenever possible. Some of @Th0m shared scripts got this systemd monitor samples which are useful as a guide for all, if they wish to learn from them.
Good afternoon Thank you very much for the clarification. Understood, we had enabled incron without really knowing what we were doing (only because we saw an error log), but now it's clear. Best regards
Good afternoon Thank you very much for the advice. We will review the scripts you mentioned. Best regards