Hello, In most cases, admins reconfigure Squid to change a small portion of the configuration while the majority of squid.conf and Squid functionality stays the same. Yet, Squid dutifully shuts almost everything down, configures modules/features almost from scratch, and then starts them up. This shutdown-configure-start behavior creates user-visible disruptions, complicates code, increases the chance of memory leaks, leads to memory overuse, may hurt caching, spoil statistics, etc.
We cannot solve this problem immediately, but we can improve old features as we go and minimize mistakes in the new code. I would like to propose the following four design principles to guide us long-term as we work on individual modules/features or add new ones: P0: Reconfiguration is not meant and will never be able to replace a full Squid shutdown and start. Some residual effects from the initial configuration are likely to persist. Some Squid features/modules/parts may never support reconfiguration. Some subtle/hidden relationships between features may not be fully tracked during reconfiguration. Our goal is to maximize the number of properly supported reconfiguration changes while minimizing reconfiguration-caused problems/disruptions. It is a complex balancing act. P1: If its configuration has not changed, the feature/module does not have to do anything in reaction to reconfigure. It may keep running and functioning as it was. It does not have to shut down and restart. For example, if configuration affecting all aspects of a listening port has not changed at all, Squid does not have to stop listening and close the corresponding socket (even if there are probably some use cases that benefit from Squid doing so). P2: Each feature/module has the right to determine what constitutes its "configuration" in P1. Even though nearly every Squid feature may have an indirect effect on other Squid features, we have to draw lines somewhere (per P0). The important thing here is consistent, predictable behavior, not 100% coverage graph of all possible inter-feature dependencies. P3. By default, if a feature/module claims that its configuration consists of N direct and related squid.conf settings (S1 ... SN), then the feature should consider its configuration unchanged if * each Si value has not changed AND * for each Si that the feature knows to be a name of a local file containing additional configuration input (e.g., a file containing an SSL certificate), the last modification timestamp of that file has not changed. P4. Any feature/module decision about its configuration changes can be overwritten by an admin. In other words, the admin has the right to force any feature to assume that its configuration has changed. How this is done and whether this is done for all features at once or selectively are separate questions not discussed here for the sake of focus. Do we agree on the above? Needless to say, the vast majority of current modules/features do not follow the above principles today. That is OK. If we agree on these principles, folks can start adjusting the existing features to meet them and ensure that newly proposed features comply when feasible. Any decision would be specific to the feature, of course, but having these principles helps. Furthermore, if we agree, we can add a simple, general API to implement P3 (and P4) logic for any feature that wants to use it without forcing other features to make changes. This will make it much easier to support these principles. Thank you, Alex. P.S. The proposed principles are mostly orthogonal (but can be added) to the "hot reconfiguration" problems currently discussed at http://wiki.squid-cache.org/Features/HotConf