Raise monit's hardcoded restriction for max
Monit uses hardcoded restriction for max number of include files.
I believe this was introduced to combat potential circular dependency of include files. This approach is simple and effective. I don't believe though this number has to be so restrictively low to serve the purpose.
This limit is actually impacting me in current environment. Details: - multi tenant environment - network, lb/app layers irrelevant to the case - monit restriction visible on separate farm of servers hosting support services for webservices - supporting services are tenant dedicated - each tenant can get different subset of supporting services activated - monit is used to monitor dozen system components on each server (dozen of config files on each server, irrelevant) - monit is used to start/watch/restart tenant services (this is when we can hit the monit restriction);
/etc/monit.d/<tenant>-<service> naming pattern for monit config files is used. This is done to retain easy control over stopping (monit from reviving) all services for specific tenant or all services of specific type for all tenants (during maintenance works on tenant or given service type).
Obviously, limit can be circumvented by putting all definitions in single file or create only handful per service config files. This however is sub-optimal - this approach requires iterating over all tenants/services and regenerating monit config file(s) every time there's a change. In current scheme this is not needed - /etc/monit.d/<tenant>-<service> are actually links to config files kept within tenant application code tree, generated once. Links are removed/recreated as needed (and monit reloaded).