Re: 1000-directory limit for svscan

On Sat, Mar 25, 2006 at 01:44:49PM -0800, Andrew Catton wrote:
> Does anyone know the reason for this hardcoded limit in svscan?   
> We're working with a fairly unusual deployment approach which  
> requires us to exceed it.  I've increased the SERVICES size, but  
> would like to know if I'm walking into some trouble that the limit  
> was meant to prevent..

It looks like svscan uses an O(n^2) algorithm in how many services 
you're running.  If you're using a large number of services, you might 
consider splitting your services into multiple /service directories 
(e.g. /service1, /service2, ...) and running svscan on each of them.

Also, I believe runit, Gerrit Pape's daemontools clone package, will not 
rescan the /service directory if its mtime has not changed, so that 
might be another useful optimization if the services you are managing do 
not change often.

(Disclaimer: I'm just speculating.  I only manage about 20 services with 
runit, so I've not had to look into benchmarking these possibilities too 
extensively.  :-)