On Thu, 25.11.10 22:43, Tomasz Torcz (to...@pipebreaker.pl) wrote: > Hi, > > I'm slowly porting init scripts of software I use to systemd unit files. > It is generally straight-forward, but today Squid made me wonder. > > Squid is web-caching daemon (proxy) with some pecularities. It > stores the cache of the internet in some directories on disk. To > paralleize access, it is recommended to define separate cache_dir for > each hard disk. Also, squid likes 2-level deep folder structure > in each cache_dir, to implement simple hashing and deal with lesser > filesystems. > > Populating each defined cache_dir can be slow operation, therefore > it is not done automatically. Fedora's squid script checks if cache_dir > is empty and if so, run the command to create folder hierarchy. > > This “populate” command is great candidate for separating into its own > unit, squid-populate.service, required by main squid.service and > using negated ConditionDirectoryNotEmpty=. > > As I mentioned, there could be more than one cache_dir definition. > For each one, separate squid-populate.service should be created, using > @ instances. (BTW, we cannot grep-out all the directories from > squid.conf, administrator needs to repeat cache_dir configuration in > systemd units).
I'd probably recommend that the squid folks write a binary or so for this which simply does this test + populate in C. It's of course an interesting excercise to map the functionality that systemd offers to all kinds of problems, but in some cases one shouldn't try too hard, I think. > Now the question: how should requires be defined? Which is better way? > 1) should squid.service explicitly require > squid-populate@/var/spool/squid/cache1.service, > …cache2.service etc? This means that administrator would need to > modify main squid.service when adding more cache_dirs In general I think there is value in doing things so that nothing needs to be edited by the admin, so that the .service files can remain untouched deep down in /lib. systemd git however supports .requires directories (similar to .wants), which you can use to do what you want without having to edit and service files. > 2) should each instance define itself as required by squid.service? If so, > how to do it? > This behaviour makes adding directories simpler. I guess here too .requires directories are the answer. > Nb. I consider using unit generator parsing squid.conf an overkill for > this task :) > > Second issue, cascading timeouts. Let's say squid-populate.service has > TimeoutSec=3m, > because it may be slow. Main squid.service has standard 1m timeout. > What happen when I run "systemctl start squid.service" with empty cache > directory? squid-populate.service will be started and may work for, let's > say, 2 minutes. Will systemctl timeout after 1m? Or after 3m+1m? As long as deps of a job are not ready the timeout of the job does not begin. Hence squid will fail after 3m+1m. > In future squid may be socket-activable. If population is needed, will > the timeout for connection be 3m (populate) + 1m (squid itself) + 1m (socket > timeout) = 5m ? Nah, the squitd and the socket timeout would be at the same time. > Side observation: systemd has only one timeout for start and stop. > Squid's sysv script defines short timeout for start and much longer > for stop (because squid waits for open connection to end when closing). Hmm, yepp, I was thinking about this, but I thought it's not too bad if the start timeout is longer than needed in this case, and I don't want to add an inflation of seperate switches here. So unless there's a really strong reason to seperate the timeouts i'd like to stay with the status quo. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
