From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Fri, 17 Jan 2014 19:32:48 +0000 Subject: The road to v0.10.1 or v0.11 In-Reply-To: <52D9848F.1070308@kernel.org> References: <20140117162851.GM7608@serenity.lan> <20140117165333.GN7608@serenity.lan> <52D9848F.1070308@kernel.org> Message-ID: <20140117193248.GQ7608@serenity.lan> On Fri, Jan 17, 2014 at 02:29:19PM -0500, Konstantin Ryabitsev wrote: > On 17/01/14 01:22 PM, Jason A. Donenfeld wrote: > >> But scan for repos is caught by the cache most of the time, and > >> > presumably even if we run persistently we still need to do that > >> > periodically (or use inotify); or do we just rely on the process being > >> > replaced when the set of repositories changes? > > Generally the idea is you restart the fcgi process when things change, > > or at least send it a SIGUSR1. But we could be fancy and support > > inotify/kqueue... > > The process that updates the repositories may not have permissions to > send SIGUSR1 to the fcgid process -- either because they are running as > different users or because there are SELinux policies preventing it. > > It's really best if cgit recognizes when things like projects.list have > changed. Presumably you are OK with this having the same latency as the existing cache mechanism. The simplest implementation will probably be to keep the existing "cache valid?" check and re-scan repositories as we currently do.