Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
S
slash
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
uplex-varnish
slash
Commits
e36c1ca6
Unverified
Commit
e36c1ca6
authored
Nov 28, 2023
by
Nils Goroll
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Document how to analyze lockups
Motivated by #41
parent
4727ce59
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
56 additions
and
0 deletions
+56
-0
BUGS.rst
BUGS.rst
+56
-0
No files found.
BUGS.rst
View file @
e36c1ca6
...
...
@@ -49,6 +49,62 @@ For a typical installation, the commands would be::
gdb --batch -ex "thr app all bt full" /usr/sbin/varnishd core
Lockups
-------
To analyze situations where varnish-cache hangs related to the use of
SLASH/ (e.g. the hang occurred only after introducing SLASH/), we need
to investigate the state of the program at the time of the hang.
There are basically two options to get there: Either analyze the still
running process with gdb, or get a core dump and analyze it
later.
Get thread dump of a running process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``gdb`` invocation is almost the same as the example given above,
but you need the pid of the Varnish-Cache *worker* process. It can
usually be found by its name ``cache-main``, so the snippet given here
uses this simple method::
cd $YOUR_VARNISH_WORKING_DIRECTORY
pid=$(pgrep cache-main)
gdb -p $pid --batch -ex "thr app all bt full"
For a typical installation, the commands would be::
cd /var/lib/varnish/$(uname -n)
pid=$(pgrep cache-main)
gdb -p $pid --batch -ex "thr app all bt full"
If, for whatever reason, this method does not work, look for a
``varnishd`` process which is the *child* of another ``varnishd``
process and use the child's pid for the ``pid`` variable.
Getting a core dump
~~~~~~~~~~~~~~~~~~~
Getting the core dump itself is straight forward: Determine the pid of
the cache worker process (see above), then run ``gcore`` on it::
pid=$(pgrep cache-main)
gcore -o slash_issue.core $pid
But to be able to make good use of the core dump, we also need the
varnish working directory, so please save that, too::
cp -pr $YOUR_VARNISH_WORKING_DIRECTORY slash_issue.workdir
For a typical installation, this is::
cp -pr /var/lib/varnish/$(uname -n) slash_issue.workdir
Then, to get the thread dump from this data, use the same command
given under `Panics`_, but use the saved workdir instead of the actual
one.
Other
-----
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment