maximum_object_size has no effect in default configuration file

[gcc]

Squid suffers from a bug or misfeature which makes the maximum_object_size in the supplied configuration file completely ineffective.

If you set debug_options = ALL,2 you will see the following line for objects over 4 MB, that should be cached if you enable it:

  store.cc(1020) checkCachable: StoreEntry::checkCachable: NO: too big

The bug is described here: http://www.spinics.net/lists/squid/msg69855.html

In summary:

"With adequate debug_options enabled, squid was saying that the object size
was too big (I've added the CL (Content-Length), SMOS (store_maxobjsize) and
EO (endOffset) variables to the log line).

2014/04/21 00:35:35.429| store.cc(1020) checkCachable:
StoreEntry::checkCachable: NO: too big (CL = 33560984; SMOS = 4194304; EO =
268)

Clearly, something was wrong with the maxobjsize, that was set in the config
to 1Gb and the log was reporting it being set to 4Mb (what I discovered
later to be the default value)...

So, if you put in your config something like this (like it
was in mine):

  cache_dir aufs /var/cache 140000 16 256
  maximum_object_size 1 GB

then the maximum_object_size option is processed and you see it at the
cachemgr config page but it has no effect as the store data structure
parameter maxobjsize was already initialized (with the default value) by
parse_cachedir before parsing the "maximum_object_size 1 GB" line, so we
have 4Mb (default) effective maximum_object_size.

If we have a config with

  maximum_object_size 1 GB
  cache_dir aufs /var/cache 140000 16 256

we get the effective maximum_object_size for the store set to 1Gb as
expected."

The Ubuntu standard configuration file (and probably upstream) have the maximum_object_size line after the cache_dir, where it has no effect. Moving it before the cache_dir line makes it work properly.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: squid3 3.3.8-1ubuntu6.2
ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.14.1-0ubuntu3.10
Architecture: amd64
Date: Thu May 28 12:56:00 2015
InstallationDate: Installed on 2015-05-17 (10 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
SourcePackage: squid3
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.squid3.squid.conf: 2015-05-28T12:50:57.224228

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

If this also affects upstream, it should be reported there if it is not already. We can cherry-pick a fix in Ubuntu but I'd prefer to do that only after an upstream commit lands so we don't end up maintaining different behaviour in Ubuntu indefinitely.

[gcc (chris+ubuntu-qwirx)]

Filed upstream.

[Robie Basak (racb)]

Thanks. Upstream says this was fixed in 3.4.5, which we don't have in Ubuntu yet. So this bug remains valid in Ubuntu.

[Amos Jeffries (yadi)]

For the record, upstream patch for this was http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13130.patch. The code part of this should apply fine to any affected version of Squid.

[Amos Jeffries (yadi)]

This is fixed in the squid package now available in Xenial.