[systemd-devel] preparing unit definition for squid – some questions
lennart at poettering.net
Thu Jan 6 17:53:02 PST 2011
On Thu, 25.11.10 22:43, Tomasz Torcz (tomek at pipebreaker.pl) wrote:
> 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
> 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
> 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
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
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel