On Tue, Jan 28, 2014 at 8:07 AM, Tollef Fog Heen <[email protected]> wrote: > ]] Dridi Boukelmoune > >> Hi, >> >> On Mon, Jan 27, 2014 at 2:57 PM, Tollef Fog Heen >> <[email protected]> wrote: >> > Hi all, >> > >> > This got triggered by bug #1415 which asks for init scripts to be able >> > to verify you're not just breaking your cache on a restart. I can see >> > the need for such a tool, but I think it should have a bit wider scope. >> > >> > Problems: >> > >> > - you don't want to restart Varnish when the configuration is >> > obviously broken. >> > >> > - it should be possible to reload configurations without having to >> > fiddle with vcl.load, vcl.use. Coming up with new names is >> > surprisingly annoying. >> > >> > - Duplication of logic between RH and Debian init scripts. Varnish >> > should probably be able to read a parameter file in some reasonable >> > format, which will also make the transition to non-sysvinit inits >> > easier. >> > >> > Suggestion 1: >> > >> > Write something like to apachectl. It knows how to run a config test, >> > start and stop the management process. It makes it easy to run >> > multiple instances (something that's more important to apache than >> > us). It's a bit like a distro-independent init script, but has custom >> > functions (configtest for instance) >> >> I find the idea compelling, but I've had issues with apachectl. > > Your problems seem to be "apachectl has bugs", and I wrote "something > like apachectl", meaning that we'll implement a different set of bugs. > :-)
As long as the bugs are well documented ;-) >> I really like the idea of a varnishctl that could be used downstream >> to build services on top of systemd, upstart etc. But I'd go for a >> simple pass-through command with simple sub-commands such as >> start/stop/restart/reload/configtest that would just add sugar such as >> "configtest on restart" and nothing more. > > In the stack, I'd want to have the init scripts call varnishctl, not the > other way around. Sorry, this is what I meant. SysVinit, systemd, upstart and the like that would use varnishctl. By downstream I mean distributions since they mean you as an upstream of their varnish packages. >> > Suggestion 2: >> > >> > Extend varnishadm to not only be able to talk to varnishd, but also >> > start and stop the management process, do a config test and so on. >> >> Would that mean 3 processes in varnishd ? > > No, that wasn't my intention. What would the third one be? I don't know ; if varnishd has only two processes as it currently has, how would you stop the management process ? I understand the feature to be similar to the current stop/start of the child process through varnishadm. Dridi _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
