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

[Kay Sievers]

On Fri, Nov 26, 2010 at 13:04, Gustavo Sverzut Barbieri
<barbieri at profusion.mobi> wrote:
> 2010/11/26 Tomasz Torcz <tomek at pipebreaker.pl>:
>> On Thu, Nov 25, 2010 at 09:31:55PM -0200, Gustavo Sverzut Barbieri wrote:
>>> On Thu, Nov 25, 2010 at 7:43 PM, 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.
>>>
>>> IMHO this is totally wrong, we're trying to solve the problem
>>> elsewhere. Squid itself should check and generate the missing
>>> directories as it will already have to load the configuration file and
>>> (probably) the cache directory structure. This is even more true that
>>> it shouldn't assume all directories exist if at least one is there
>>> (ie: it is not empty, but not all required are there).
>>
>>  Well, but the Squid won't generate them on normal startup and
>> I'm trying to not lose functionality from original sysv script.
>> Squid will create directiories when asked to (`squid -z`) but
>> it will take time and is special case, hence supplementary unit file.
>
> I don't see how doing this in squid is slower than doing it elsewhere.
> If you mean that -z will force squid to not just check $CACHEDIR but
> $CACHEDIR/*, then as I said this is the correct behavior and you'd
> have to have all of those directories as condition to trigger
> recreating the cache, otherwise it may result in runtime failures.
>
> I'd like to see what others think about that, but IMO squid -z should
> be used in squid.service

Right, environment preparation for a service should be provided by the
service itself, and not in any external script. It can be a separate
binary, or the daemon itself, but it should not live in custom shell
scripts, or init scripts. Squid is the only thing that expects
something here, knows what it expects, so it should prepare that
itself.

> If squid -z will ALWAYS recreate directories, then we could patch it
> to just create what is required. Or add that as another flag. One of
> the points with systemd is push services to do their things in the
> right way, like use configure files to avoid nasty /etc/conf.d or
> /etc/sysconfig, to use socket-activation, etc.

Yep.

>>  It's not a precedent. NTPD's sysv script was split during port
>> to run ntpdate as separate unit.  udev's was even split into 3
>> services.
>
> I can't comment on it, however I find ntpd a bad example for most of
> things as it has so many wrong things, like the lack of proper network
> handling. And it should be managed by the network system itself
> (connman, networkmanager)

Right.

> udev is an example of the hacks you have to do to support
> broken/legacy systems, as udev-settle.service should not be used in an
> ideal world, since people would be hotplug-aware and not rely on
> "system being ready" as there is no such concept as Kay keeps saying.

Udev was always 2 scripts, the split of the first one now, is just to
keep the legacy part not blocking proper services -- which don't need
to wait for udev anymore, because of devtmpfs.

Broken stuff can depend on the settle thing and will be delayed until
it wrongly can assume something, that does only exist when making the
wrong assumptions. :)

Cheers,
Kay