3.2: Squid Command Line Options
3.2.1: Help
To get a complete list of Squid's command-line options, with a short
description of each option, use the '-h' option.
3.2.2: HTTP Port
Option: -a
Format: -a port number
Example: squid -a 3128
Squid will normally accept incoming HTTP requests on the port specified in
the squid.conf file with the http_port tag. If you wish to override the tag
for some reason, you can use the '-a' option.
3.2.3: Debug Information
Option: -d
Format: -d debug level value
Example: squid -d 3
By default Squid only logs fatal errors to the screen, logging all other
errors to the cache.log file.
If you wish to log more information (for example debugging information,
rather than only errors)
The "-d" option allows you to increase the amount of debug information
logged to the screen. If squid is started from your startup scripts, then
this output will appear on the console of the machine. If started from a
remote login, this output will be written to the screen of your remote
session.
3.2.4: Config file
Option: -f
Format: -f path
Example: squid -f /usr/local/etc/squid.conf
This option allows you to specify a different path to the squid config file.
When installing a binary version of squid, the default path to the
squid.conf file may be inappropriate to your system.
If you wish to test a different version of the config file, but wish to be
able to revert to the previous config file in a hurry, you can use this
option to refer to a different config file. To change back to the other
config file you just have to restart Squid without this option.
3.2.5: Signaling a running Squid
Option: -k
Format: -k action
Example: squid -k rotate
You can communicate with a running copy of Squid by sending it signals.
These signals will cause Squid to perform maintenance functions, doing
things like reloading the config file, rotating the logs (for analysis) and
so forth.
On some operating systems certain signals are reserved. The threads library
on Linux, for example, uses the SIGUSR1 and SIGUSR2 signals for thread
communication.
Sending the wrong signal to a running Squid is easy, and can have
unfortunate consequences.
This option allows you to use descriptive options to send a running Squid
signals, creating a standardized cross-platform user interface.
Tag: reconfigure
Action: Reloads the squid.conf file.
Description:
It's important to note that when Squid re-reads this file it
closes all current connections, which means that clients that were
downloading files will be cut off mid-download. You should only
schedule reloads for after-hours, when their impact is minimal.
Tag: rotate
Action: Rotates the cache.log and access.log files
Description:
Cache log files get very large. To stop the log files using
up all your disk space you should rotate the logs daily.
The squid.conf logfile_rotate option sets the maximum number of
rotated logs that you wish to keep.
The most common use of this action is to rotate the logs just
before logfile analysis (see Chapter 10). A crontab signals
the rotation, sleeps for a short time, and then calls the logfile
analysis program.
Tags: shutdown, interrupt
Action: Closes current connections, writes index and exits
Description:
Squid keeps an index of cache objects in memory. When you wish to
shutdown Squid you should use this option, rather than simply
killing Squid. Shutting down Squid can take a short while, while it
writes the object index to disk. Squid writes to the cache.log
file while it shuts down, indicating how many objects it has
written to the index.
Both the shutdown and interrupt tag have the same effect. (?why
I thing it's since there isn't a "kill" command for NT?)
Tag: kill
Action: Kills the Squid process
Description:
The kill tag should only be used if shutdown or interrupt have
no effect. Using this tag will kill Squid without giving it a
chance to write the cache index file, causing a slow rebuild on the
next start.
Tag: debug
Action: Turns on maximum debugging
Description:
At times it is useful to see exactly what the running copy of Squid
is doing. Using the debug option will turn maximum logging on for
the main Squid process. The output is very verbose, and with a
heavily loaded cache can consume megabytes of disk space, so use
this only on a lightly loaded cache, and for small periods of time.
Tag: check
Action: Prints an error message if Squid isn't running
Description:
Using this tag causes a 'kill -0' signal to the running copy of
Squid. This doesn't do anything to the running process, other than
check that it exists (and that the user running the command has
permission to send signals to the process).
3.2.5: Logging to syslog
Option: -s
Format: -s
Example: squid -s
Squid normally logs events and debug information to a special file,
normally stored in "/usr/local/squid/logs/cache.log".
In some environments you may wish for events to be logged to central "log
server", using syslog.
Turning on this flag will
are not logged to syslog. Logs of client accesses are stored in
the file "/usr/local/squid/logs/access.log"
------------------
cache_dir:
Squid is designed with the ability to store millions of objects. Given that
many operating systems have a limit on file size it's not feasible for a
cross platform program like Squid to store all objects in one file, though
there are patches to allow users to create squid stores on large files or
on raw devices.
If you run a news server you will probably have an idea of how slow it is
to do a directory listing of a directory with hundreds of thousands of
files in it. On almost all filesystems there is a linear slowdown as more
files are added to a directory. This rules out the other option, creating
unique filenames and storing them all in one directory.
Squid uses a hierarchy of directories for file storage. The default setup
creates 16 first-tier directories. Each one of these directories then
contains 256 second-tier directories. Files are only stored in the
second-tier directories. This