On 11/06/2013 06:39 PM, Alex Rousskov wrote:
On 11/06/2013 04:46 AM, Eliezer Croitoru wrote:
On 11/06/2013 12:00 AM, Alex Rousskov wrote:
If we make squid-z a no-op, startup scripts that do not verify that
squid-z worked will continue to work fine. However, there will be some
upgrade pains for admins that use more complex startup scripts today. On
the other hand, many of the admins are already experiencing upgrade
pains because of how squid-z interacts with SMP now. It is difficult for
me to say what kind of pain is preferable, but I think we should
seriously [re]consider making squid-z a no-op as sketched above.
I was wondering why would the admin want to find and manage the
cache_dir by the startup script although it cannot determine anything
about this cache_dir (corruption etc...).
AFAICT, there are no known use cases where the admin _wants_ to manage
the cache_dir internals. All known use cases are the result of current
Squid implementation _forcing_ the admin to manage the cache_dir
internals by detecting and creating missing directories. As you have
said, the startup script does not have enough information to do this
management correctly in many cases.
In a case there are objects in the cache_dir that you dont want to erase
if there was a read\write error..
In the above case "squid -z" like operation is not wanted.
For now I found it very nice to have the -z option since sometimes there
are troubles that can be discovered by "squid -z" and not later on find
it in the cache.log.
Can you detail this a bit please? Are you talking about running squid -z
manually or from an unattented startup script? What kind of troubles do
you discover by running "squid -z" that you cannot discover by running
"squid".
Manually.
I have used glusterfs to store aufs cache_dir and when I wanted to
create the cache_dir I had a small problem:
squid -z resulted in a "flying" process that throws to STDOUT errors
about permissions of the creation of the cache_dir directories.
it's not about not discovering by squid but rather "squid -z" will leave
a daemon\process\fork open while the only way of knowing about it is the
cache.log while still throwing errors to the STDOUT.
I assume that reading these errors from cache.log should alert the admin
but I also will want to support the systemd journal in a way.
I will need to check this situation on a server like OpenSUSE that has
full systemd support.
What would be the alternative to get on STDOUT error messages on "squid
-z"?
I am not sure I understand the question, but perhaps the answer is
"squid -d1" or "tail -f cache.log"?
So for a systemd based system we will run squid with "squid -d1"?? to
log the needed information into the journal?
which ALL,1 should be logged this way if I am right about it.
systemd uses STDOUT\ERR and exit codes (standard way of doing things) to
log in the "journal" which is a nice thing.
So would squid in SMP will\should use exit code of the startup process
to reflect the status of the cache_dir ??
If cache_dir directory is missing and Squid is prohibited from creating
it or ignoring the cache_dir, then Squid instance should exit with a
non-zero exit code. This behavior should be the same for SMP and non-SMP
cases.
OK
Thanks,
Eliezer
