[systemd-devel] preparing unit definition for squid – some questions

[Lennart Poettering]

On Thu, 25.11.10 22:43, Tomasz Torcz (tomek at 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.