Commit 58c194f6 authored by Amy Qualls's avatar Amy Qualls Committed by Marcel Amirault

Add language declarations to code blocks

Adding more language declarations to code blocks.
parent c81c5202
......@@ -33,7 +33,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
```ruby
irb(main):002:0> ActionMailer::Base.smtp_settings
=> {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}```
=> {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}
```
In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
......@@ -56,13 +56,13 @@ For more advanced issues, `gdb` is a must-have tool for debugging issues.
To install on Ubuntu/Debian:
```
```shell
sudo apt-get install gdb
```
On CentOS:
```
```shell
sudo yum install gdb
```
......@@ -103,14 +103,14 @@ downtime. Otherwise skip to the next section.
1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
1. In the gdb window, type:
```
```plaintext
call (void) rb_backtrace()
```
1. This forces the process to generate a Ruby backtrace. Check
`/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtace. For example, you may see:
```ruby
```plaintext
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
......@@ -124,13 +124,13 @@ downtime. Otherwise skip to the next section.
1. To see the current threads, run:
```
```plaintext
thread apply all bt
```
1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
```
```plaintext
detach
exit
```
......@@ -162,7 +162,7 @@ separate Rails process to debug the issue:
1. Create a Personal Access Token for your user (Profile Settings -> Access Tokens).
1. Bring up the GitLab Rails console. For omnibus users, run:
```
```shell
sudo gitlab-rails console
```
......
......@@ -99,13 +99,13 @@ References:
- [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [Google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
- [Issue #2 deadlocks can occur if an instance is flooded with pushes](https://gitlab.com/gitlab-org/gitlab/issues/33650). Provided for context about how GitLab code can have this sort of unanticipated effect in unusual situations.
```
```plaintext
ERROR: deadlock detected
```
Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528); our recommended settings are as follows:
```
```ini
deadlock_timeout = 5s
statement_timeout = 15s
idle_in_transaction_session_timeout = 60s
......@@ -128,7 +128,7 @@ Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indica
See current settings with:
```
```shell
sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
puts c.execute('SHOW lock_timeout').to_a ;
puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
......
......@@ -31,7 +31,7 @@ Check in `/var/log/gitlab/sidekiq/current` or `$GITLAB_HOME/log/sidekiq.log` for
the backtrace output. The backtraces will be lengthy and generally start with
several `WARN` level messages. Here's an example of a single thread's backtrace:
```
```plaintext
2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: ActiveRecord::RecordNotFound: Couldn't find Note with 'id'=3375386
2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.2.5.2/lib/active_record/core.rb:155:in `find'
/opt/gitlab/embedded/service/gitlab-rails/app/workers/new_note_worker.rb:7:in `perform'
......@@ -55,7 +55,7 @@ respond to the `TTIN` signal, this is a good next step.
If `perf` is not installed on your system, install it with `apt-get` or `yum`:
```
```shell
# Debian
sudo apt-get install linux-tools
......@@ -68,13 +68,13 @@ sudo yum install perf
Run perf against the Sidekiq PID:
```
```shell
sudo perf record -p <sidekiq_pid>
```
Let this run for 30-60 seconds and then press Ctrl-C. Then view the perf report:
```
```shell
sudo perf report
# Sample output
......@@ -102,13 +102,13 @@ of the process (Sidekiq will not process jobs while `gdb` is attached).
Start by attaching to the Sidekiq PID:
```
```shell
gdb -p <sidekiq_pid>
```
Then gather information on all the threads:
```
```plaintext
info threads
# Example output
......@@ -129,7 +129,7 @@ from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokog
If you see a suspicious thread, like the Nokogiri one above, you may want
to get more information:
```
```plaintext
thread 21
bt
......@@ -147,7 +147,7 @@ bt
To output a backtrace from all threads at once:
```
```plaintext
set pagination off
thread apply all bt
```
......@@ -155,7 +155,7 @@ thread apply all bt
Once you're done debugging with `gdb`, be sure to detach from the process and
exit:
```
```plaintext
detach
exit
```
......
......@@ -153,7 +153,7 @@ Note that Oracle Cloud S3 must be sure to use the following settings:
If `enable_signature_v4_streaming` is set to `true`, you may see the
following error:
```
```plaintext
STREAMING-AWS4-HMAC-SHA256-PAYLOAD is not supported
```
......
......@@ -17,7 +17,7 @@ The response has three fields:
This API endpoint is only available to admin users.
```
```plaintext
DELETE /admin/sidekiq/queues/:queue_name
```
......
......@@ -49,7 +49,7 @@ The web application flow is:
1. Request authorization code. To do that, you should redirect the user to the
`/oauth/authorize` endpoint with the following GET parameters:
```
```plaintext
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=YOUR_UNIQUE_STATE_HASH&scope=REQUESTED_SCOPES
```
......@@ -60,7 +60,7 @@ The web application flow is:
would request `read_user` and `profile` scopes). The redirect will
include the GET `code` parameter, for example:
```
```plaintext
http://myapp.com/oauth/redirect?code=1234567890&state=YOUR_UNIQUE_STATE_HASH
```
......
......@@ -123,7 +123,7 @@ pagination models.
To expose a collection of resources we can use a connection type. This wraps the array with default pagination fields. For example a query for project-pipelines could look like this:
```
```graphql
query($project_path: ID!) {
project(fullPath: $project_path) {
pipelines(first: 2) {
......@@ -181,7 +181,7 @@ look like this:
To get the next page, the cursor of the last known element could be
passed:
```
```graphql
query($project_path: ID!) {
project(fullPath: $project_path) {
pipelines(first: 2, after: "Njc=") {
......@@ -319,7 +319,6 @@ module Types
value 'CLOSED', value: 'closed', description: 'An closed Epic'
end
end
```
## Descriptions
......
......@@ -542,28 +542,28 @@ See the README for more information.
The GitLab init script starts and stops Unicorn and Sidekiq:
```
```plaintext
/etc/init.d/gitlab
Usage: service gitlab {start|stop|restart|reload|status}
```
Redis (key-value store/non-persistent database):
```
```plaintext
/etc/init.d/redis
Usage: /etc/init.d/redis {start|stop|status|restart|condrestart|try-restart}
```
SSH daemon:
```
```plaintext
/etc/init.d/sshd
Usage: /etc/init.d/sshd {start|stop|restart|reload|force-reload|condrestart|try-restart|status}
```
Web server (one of the following):
```
```plaintext
/etc/init.d/httpd
Usage: httpd {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}
......@@ -573,7 +573,7 @@ Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}
Persistent database:
```
```plaintext
$ /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|restart|reload|force-reload|status} [version ..]
```
......@@ -626,7 +626,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
In a nutshell, do the following:
```
```shell
sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
......
......@@ -47,7 +47,7 @@ To simulate a memory leak in your application, use the `/-/chaos/leakmem` endpoi
NOTE: **Note:**
The memory is not retained after the request finishes. Once the request has completed, the Ruby garbage collector will attempt to recover the memory.
```
```plaintext
GET /-/chaos/leakmem
GET /-/chaos/leakmem?memory_mb=1024
GET /-/chaos/leakmem?memory_mb=1024&duration_s=50
......@@ -72,7 +72,7 @@ This endpoint attempts to fully utilise a single core, at 100%, for the given pe
Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
If you're using Unicorn, this is done by killing the worker process.
```
```plaintext
GET /-/chaos/cpu_spin
GET /-/chaos/cpu_spin?duration_s=50
GET /-/chaos/cpu_spin?duration_s=50&async=true
......@@ -96,7 +96,7 @@ This endpoint can be used to model yielding execution to another threads when ru
Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
If you're using Unicorn, this is done by killing the worker process.
```
```plaintext
GET /-/chaos/db_spin
GET /-/chaos/db_spin?duration_s=50
GET /-/chaos/db_spin?duration_s=50&async=true
......@@ -119,7 +119,7 @@ This endpoint is similar to the CPU Spin endpoint but simulates off-processor ac
As with the CPU Spin endpoint, this may lead to your request timing out if duration_s exceeds the configured limit.
```
```plaintext
GET /-/chaos/sleep
GET /-/chaos/sleep?duration_s=50
GET /-/chaos/sleep?duration_s=50&async=true
......@@ -142,7 +142,7 @@ This endpoint will simulate the unexpected death of a worker process using a `ki
NOTE: **Note:**
Since this endpoint uses the `KILL` signal, the worker is not given a chance to cleanup or shutdown.
```
```plaintext
GET /-/chaos/kill
GET /-/chaos/kill?async=true
```
......
......@@ -39,7 +39,7 @@ If your test DB is giving you problems, it is safe to nuke it because it doesn't
Access the database via one of these commands (they all get you to the same place)
```
```ruby
gdk psql -d gitlabhq_development
bundle exec rails dbconsole RAILS_ENV=development
bundle exec rails db RAILS_ENV=development
......
......@@ -10,7 +10,7 @@ data leaks.
On the staging VM, add the following line to `/etc/gitlab/gitlab.rb` to speed up
large database imports.
```
```shell
# On STAGING
echo "postgresql['checkpoint_segments'] = 64" | sudo tee -a /etc/gitlab/gitlab.rb
sudo touch /etc/gitlab/skip-auto-reconfigure
......@@ -23,7 +23,7 @@ Next, we let the production environment stream a compressed SQL dump to our
local machine via SSH, and redirect this stream to a psql client on the staging
VM.
```
```shell
# On LOCAL MACHINE
ssh -C gitlab.example.com sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -Cc gitlabhq_production |\
ssh -C staging-vm sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -d template1
......@@ -37,14 +37,14 @@ use this procedure.
First, on the production server, create a list of directories you want to
re-create.
```
```shell
# On PRODUCTION
(umask 077; sudo find /var/opt/gitlab/git-data/repositories -maxdepth 1 -type d -print0 > directories.txt)
```
Copy `directories.txt` to the staging server and create the directories there.
```
```shell
# On STAGING
sudo -u git xargs -0 mkdir -p < directories.txt
```
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment