passenger 5.0.14 → 5.0.15

Sign up to get free protection for your applications and to get access to all the features.

Potentially problematic release.


This version of passenger might be problematic. Click here for more details.

Files changed (70) hide show
  1. checksums.yaml +8 -8
  2. checksums.yaml.gz.asc +7 -7
  3. data.tar.gz.asc +7 -7
  4. data/CHANGELOG +9 -0
  5. data/INSTALL.md +1 -1
  6. data/LICENSE +1 -1
  7. data/README.md +1 -1
  8. data/bin/passenger-install-apache2-module +6 -10
  9. data/bin/passenger-install-nginx-module +6 -9
  10. data/doc/CloudLicensingConfiguration.html +1 -216
  11. data/doc/CloudLicensingConfiguration.txt.md +1 -192
  12. data/doc/Design and Architecture.html +4 -4
  13. data/doc/Design and Architecture.txt +4 -4
  14. data/doc/ServerOptimizationGuide.html +1 -489
  15. data/doc/ServerOptimizationGuide.txt.md +1 -399
  16. data/doc/Users guide Apache.html +594 -6720
  17. data/doc/Users guide Apache.idmap.txt +15 -12
  18. data/doc/Users guide Apache.txt +113 -2047
  19. data/doc/Users guide Nginx.html +565 -6720
  20. data/doc/Users guide Nginx.idmap.txt +15 -12
  21. data/doc/Users guide Nginx.txt +94 -1862
  22. data/doc/Users guide Standalone.html +53 -2183
  23. data/doc/Users guide Standalone.idmap.txt +9 -6
  24. data/doc/Users guide Standalone.txt +16 -360
  25. data/doc/Users guide.html +3 -145
  26. data/doc/Users guide.txt +2 -54
  27. data/doc/users_guide_snippets/analysis_and_system_maintenance.txt +36 -175
  28. data/doc/users_guide_snippets/appendix_c_spawning_methods.txt +9 -215
  29. data/doc/users_guide_snippets/environment_variables.txt +11 -243
  30. data/doc/users_guide_snippets/installation.txt +66 -946
  31. data/doc/users_guide_snippets/rackup_specifications.txt +1 -75
  32. data/doc/users_guide_snippets/support_information.txt +1 -48
  33. data/doc/users_guide_snippets/tips.txt +103 -704
  34. data/doc/users_guide_snippets/troubleshooting/default.txt +16 -130
  35. data/doc/users_guide_snippets/troubleshooting/rails.txt +15 -12
  36. data/doc/users_guide_snippets/under_the_hood/relationship_with_ruby.txt +2 -113
  37. data/ext/apache2/Configuration.hpp +2 -2
  38. data/ext/apache2/Hooks.cpp +2 -2
  39. data/ext/common/AgentsStarter.h +18 -10
  40. data/ext/common/ApplicationPool2/ErrorRenderer.h +0 -3
  41. data/ext/common/ApplicationPool2/Options.h +8 -1
  42. data/ext/common/Constants.h +3 -9
  43. data/ext/common/agent/Core/RequestHandler/InitRequest.cpp +2 -0
  44. data/ext/common/agent/Watchdog/Main.cpp +1 -1
  45. data/ext/nginx/ContentHandler.c +2 -3
  46. data/ext/nginx/config +2 -2
  47. data/lib/phusion_passenger.rb +1 -22
  48. data/lib/phusion_passenger/abstract_installer.rb +10 -10
  49. data/lib/phusion_passenger/config/agent_compiler.rb +5 -5
  50. data/lib/phusion_passenger/config/nginx_engine_compiler.rb +4 -4
  51. data/lib/phusion_passenger/config/validate_install_command.rb +3 -3
  52. data/lib/phusion_passenger/constants.rb +1 -5
  53. data/lib/phusion_passenger/loader_shared_helpers.rb +16 -5
  54. data/lib/phusion_passenger/platform_info/apache_detector.rb +2 -2
  55. data/lib/phusion_passenger/public_api.rb +11 -2
  56. data/lib/phusion_passenger/request_handler/thread_handler.rb +2 -3
  57. data/lib/phusion_passenger/ruby_core_io_enhancements.rb +4 -1
  58. data/lib/phusion_passenger/standalone/start_command.rb +1 -1
  59. data/resources/oss-binaries.phusionpassenger.com.crt +124 -0
  60. data/resources/templates/apache2/deployment_example.txt.erb +5 -23
  61. data/resources/templates/apache2/installing_against_a_different_apache.txt.erb +3 -4
  62. data/resources/templates/apache2/possible_solutions_for_compilation_and_installation_problems.txt.erb +3 -3
  63. data/resources/templates/apache2/rpm_installation_recommended.txt.erb +1 -1
  64. data/resources/templates/installer_common/low_amount_of_memory_warning.txt.erb +4 -5
  65. data/resources/templates/nginx/deployment_example.txt.erb +5 -17
  66. data/resources/templates/nginx/possible_solutions_for_compilation_and_installation_problems.txt.erb +3 -3
  67. data/resources/templates/standalone/config.erb +1 -1
  68. data/resources/templates/undisclosed_error.html.template +4 -11
  69. metadata +2 -2
  70. metadata.gz.asc +7 -7
@@ -1,242 +1,36 @@
1
1
  [[spawning_methods_explained]]
2
2
  == Appendix C: Spawning methods explained
3
3
 
4
- At its core, Phusion Passenger is an HTTP proxy and process manager. It spawns
5
- application processes and forwards incoming HTTP request to one of them.
6
-
7
- While this may sound simple, there's not just one way to spawn application processes.
8
- Let's go over the different spawning methods. For simplicity's sake, let's
9
- assume that we're only talking about Ruby on Rails applications.
4
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
10
5
 
11
6
  === The most straightforward and traditional way: direct spawning
12
7
 
13
- Phusion Passenger could create a new Ruby process, which will then load the
14
- Rails application along with the entire Rails framework. This process will then
15
- enter an request handling main loop.
16
-
17
- This is the most straightforward way to spawn processes, and each process contains
18
- a full copy of the Rails application and the Rails framework in memory.
8
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
19
9
 
20
10
  === The smart spawning method
21
11
 
22
- NOTE: Smart spawning is only supported for Ruby applications. It's not supported for other languages.
23
-
24
- While direct spawning works well, it's not as efficient as it could be
25
- because each process has its own private copy of the Rails application
26
- as well as the Rails framework. This wastes memory as well as startup time.
27
-
28
- image:images/direct_spawning.png[Application processes and direct spawning] +
29
- 'Figure: Application processes and direct spawning. Each process has its
30
- own private copy of the application code and Rails framework code.'
31
-
32
- It is possible to make the different processes share the memory occupied
33
- by application and Rails framework code, by utilizing so-called
34
- copy-on-write semantics of the virtual memory system on modern operating
35
- systems. As a side effect, the startup time is also reduced. This is technique
36
- is exploited by Phusion Passenger's 'smart' spawn method.
37
-
38
- The 'smart' spawn method is similar to Unicorn's `preload_app true` feature.
12
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
39
13
 
40
14
  ==== How it works
41
15
 
42
- When the 'smart' spawn method is being used, Phusion Passenger will first
43
- create a so-called 'preloader' process. This process loads the
44
- entire Rails application along with the Rails framework, by evaluating
45
- `config.ru`. Then, whenever Phusion Passenger needs a new application process,
46
- it will instruct the preloader to create one. The preloader then then spawns
47
- a child process, which is an exact virtual copy of itself. This child process
48
- therefore already has the application code and the Rails framework code in memory.
49
-
50
- Creating a process like this is very fast, about 10 times faster than loading the
51
- Rails application/framework from scratch. On top of that, the OS also applies an
52
- optimization called 'copy-on-write'. This means that all memory that the child
53
- process hasn't modified, is shared with the parent process.
54
-
55
- image:images/smart_spawning.png[] +
56
- 'Figure: Application processes and the smart spawn method. All processes,
57
- as well as the preloader, share the same application code and Rails
58
- framework code.'
59
-
60
- However, Ruby can only leverage this copy-on-write optimization if its garbage
61
- collector is friendly. This is only the case starting from Ruby 2.0.0. Earlier
62
- versions cannot leverage copy-on-write optimizations.
63
-
64
- Note that preloader processes have an idle timeout just like application processes.
65
- If a preloader hasn't been instructed to do anything for a while, it will be shutdown
66
- in order to conserve memory. This idle timeout is configurable.
16
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
67
17
 
68
18
  ==== Summary of benefits
69
19
 
70
- Suppose that Phusion Passenger needs a process for an application
71
- that uses Rails 4.1.0.
72
-
73
- If the 'smart' spawning method is used, and a preloader for this application is
74
- already running, then process creation time is about 10 times faster than direct
75
- spawning. This process will also share application and Rails framework code memory
76
- with the preloader, as well as with other processes that have been spawned by the
77
- same preloader.
78
-
79
- In practice, the smart spawning method could mean a memory saving of about 33%,
80
- assuming that your Ruby interpreter is copy-on-write friendly.
81
-
82
- Of course, smart spawning is not without caveats. But if you understand the
83
- caveats you can easily reap the benefits of smart spawning.
20
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
84
21
 
85
22
  === Smart spawning caveat #1: unintentional file descriptor sharing
86
23
 
87
- Because application processes are created by forking from a preloader process,
88
- it will share all file descriptors that are opened by the
89
- preloader process. (This is part of the semantics of the Unix
90
- 'fork()' system call. You might want to Google it if you're not familiar with
91
- it.) A file descriptor is a handle which can be an opened file, an opened socket
92
- connection, a pipe, etc. If different application processes write to such a file
93
- descriptor at the same time, then their write calls will be interleaved, which
94
- may potentially cause problems.
95
-
96
- The problem commonly involves socket connections that are unintentionally being
97
- shared. You can fix it by closing and reestablishing the connection when Phusion
98
- Passenger is creating a new application process. Phusion Passenger provides the API
99
- call `PhusionPassenger.on_event(:starting_worker_process)` to do so. So you
100
- could insert the following code in your 'config.ru':
101
-
102
- [source, ruby]
103
- -----------------------------------------
104
- if defined?(PhusionPassenger)
105
- PhusionPassenger.on_event(:starting_worker_process) do |forked|
106
- if forked
107
- # We're in smart spawning mode.
108
- ... code to reestablish socket connections here ...
109
- else
110
- # We're in direct spawning mode. We don't need to do anything.
111
- end
112
- end
113
- end
114
- -----------------------------------------
115
-
116
- Note that Phusion Passenger automatically reestablishes the connection to the
117
- database upon creating a new application process, which is why you normally do not
118
- encounter any database issues when using smart spawning mode.
24
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
119
25
 
120
26
  ==== Example 1: Memcached connection sharing (harmful)
121
27
 
122
- Suppose we have a Rails application that connects to a Memcached server in
123
- 'environment.rb'. This causes the preloader to have a socket connection
124
- (file descriptor) to the Memcached server, as shown in the following figure:
125
-
126
- +--------------------+
127
- | Preloader |-----------[Memcached server]
128
- +--------------------+
129
-
130
- Phusion Passenger then proceeds with creating a new Rails application process, which
131
- is to process incoming HTTP requests. The result will look like this:
132
-
133
- +--------------------+
134
- | Preloader |------+----[Memcached server]
135
- +--------------------+ |
136
- |
137
- +--------------------+ |
138
- | App process 1 |-----/
139
- +--------------------+
140
-
141
- Since a 'fork()' makes a (virtual) complete copy of a process, all its file
142
- descriptors will be copied as well. What we see here is that Preloader
143
- and App process 1 both share the same connection to Memcached.
144
-
145
- Now supposed that your site gets a sudden large surge of traffic, and Phusion Passenger needs to
146
- spawn another process. It does so by forking Preloader. The result is now as follows:
147
-
148
- +--------------------+
149
- | Preloader |------+----[Memcached server]
150
- +--------------------+ |
151
- |
152
- +--------------------+ |
153
- | App process 1 |-----/|
154
- +--------------------+ |
155
- |
156
- +--------------------+ |
157
- | App process 2 |-----/
158
- +--------------------+
159
-
160
- As you can see, App process 1 and App process 2 have the same Memcached
161
- connection.
162
-
163
- Suppose that users Joe and Jane visit your website at the same time. Joe's
164
- request is handled by App process 1, and Jane's request is handled by App
165
- process 2. Both application processes want to fetch something from Memcached. Suppose
166
- that in order to do that, both handlers need to send a "FETCH" command to Memcached.
167
-
168
- But suppose that, after App process 1 having only sent "FE", a context switch
169
- occurs, and App process 2 starts sending a "FETCH" command to Memcached as
170
- well. If App process 2 succeeds in sending only one bye, 'F', then Memcached
171
- will receive a command which begins with "FEF", a command that it does not
172
- recognize. In other words: the data from both handlers get interleaved. And thus
173
- Memcached is forced to handle this as an error.
174
-
175
- This problem can be solved by reestablishing the connection to Memcached after forking:
176
-
177
- +--------------------+
178
- | Preloader |------+----[Memcached server]
179
- +--------------------+ | |
180
- | |
181
- +--------------------+ | |
182
- | App process 1 |-----/| |
183
- +--------------------+ | | <--- created this
184
- X | new
185
- | connection
186
- X <-- closed this |
187
- +--------------------+ | old |
188
- | App process 2 |-----/ connection |
189
- +--------------------+ |
190
- | |
191
- +-------------------------------------+
192
-
193
- App process 2 now has its own, separate communication channel with Memcached.
194
- The code in 'environment.rb' looks like this:
195
-
196
- [source, ruby]
197
- -----------------------------------------
198
- if defined?(PhusionPassenger)
199
- PhusionPassenger.on_event(:starting_worker_process) do |forked|
200
- if forked
201
- # We're in smart spawning mode.
202
- reestablish_connection_to_memcached
203
- else
204
- # We're in direct spawning mode. We don't need to do anything.
205
- end
206
- end
207
- end
208
- -----------------------------------------
28
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
209
29
 
210
30
  ==== Example 2: Log file sharing (not harmful)
211
31
 
212
- There are also cases in which unintentional file descriptor sharing is not harmful.
213
- One such case is log file file descriptor sharing. Even if two processes write
214
- to the log file at the same time, the worst thing that can happen is that the
215
- data in the log file is interleaved.
216
-
217
- To guarantee that the data written to the log file is never interleaved, you
218
- must synchronize write access via an inter-process synchronization mechanism,
219
- such as file locks. Reopening the log file, like you would have done in the
220
- Memcached example, doesn't help.
32
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
221
33
 
222
34
  === Smart spawning caveat #2: the need to revive threads
223
35
 
224
- Another part of the 'fork()' system call's semantics is the fact that threads
225
- disappear after a fork call. So if you've created any threads in environment.rb,
226
- then those threads will no longer be running in newly created application process.
227
- You need to revive them when a new process is created. Use the
228
- `:starting_worker_process` event that Phusion Passenger provides, like this:
229
-
230
- [source, ruby]
231
- -----------------------------------------
232
- if defined?(PhusionPassenger)
233
- PhusionPassenger.on_event(:starting_worker_process) do |forked|
234
- if forked
235
- # We're in smart spawning mode.
236
- ... code to revive threads here ...
237
- else
238
- # We're in direct spawning mode. We don't need to do anything.
239
- end
240
- end
241
- end
242
- -----------------------------------------
36
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
@@ -1,276 +1,44 @@
1
- Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the `PATH` variable) or where to look for libraries (`LD_LIBRARY_PATH`). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign `$` in front, but that's the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign `$` is a shell syntax for refering to an environment variable, as you will learn later.
2
-
3
- Environment variables are set on a **per-process** basis, but they are **inherited** by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.
4
-
5
- The per-process nature of environment variables some implications. When you set environment variables in your `bashrc` or other bash startup files...
6
-
7
- * ...only newly spawned bash shells see them.
8
- * ...the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.
9
- * ...cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.
10
-
11
- NOTE: Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.
1
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html
12
2
 
13
3
  === Working with environment variables
14
4
 
15
- You can see all environment variables in your shell by running the following command:
16
-
17
- [source,sh]
18
- ---------------------------------
19
- env
20
- ---------------------------------
21
-
22
- You can set an evironment variable with the syntax `export <NAME>=<VALUE>`. For example, to set the `APXS2` variable to the value `/usr/sbin/apxs2`:
23
-
24
- [source,sh]
25
- ---------------------------------
26
- export APXS2=/usr/sbin/apxs2
27
- ---------------------------------
28
-
29
- Any process that you run from your shell from that point on will have said environment variable:
30
-
31
- [source,sh]
32
- ---------------------------------
33
- export APXS2=/usr/sbin/apxs2
34
- ruby -e 'p ENV["APXS2"]'
35
- # => "/usr/sbin/apxs2"
36
- ---------------------------------
37
-
38
- .The "export" keyword is important
39
- [NOTE]
40
- ===================================================
41
- You **must** set the `export` keyword. If you omit the `export` keyword then the environment variable will not be visible to other processes:
42
-
43
- [source,sh]
44
- ---------------------------------
45
- APXS2=/usr/sbin/apxs2
46
- ruby -e 'p ENV["APXS2"]'
47
- # => nil
48
- ---------------------------------
49
- ===================================================
50
-
51
- You can reference an environment variable in your shell by typing the `$` sign followed by the environment variable's name. For example, to see the value of the `PATH` variable:
52
-
53
- [source,sh]
54
- ---------------------------------
55
- echo $PATH
56
- ---------------------------------
57
-
58
- You can also use this trick to extend the value of an environment variable:
59
-
60
- [source,sh]
61
- ---------------------------------
62
- export PATH=/usr/bin
63
-
64
- # Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
65
- export PATH=/opt/local/bin:$PATH
66
- # Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
67
- export PATH=$PATH:/usr/local/bin
68
- ---------------------------------
5
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#working-with-environment-variables
69
6
 
70
7
  [[the_path_env_var]]
71
8
  === The PATH environment variable
72
9
 
73
- The `PATH` environment variable dictates where the system looks for command. It is a colon-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting `PATH` will help. For example suppose that the command `frobnicator` is in `/opt/local/bin`:
74
-
75
- [source,sh]
76
- ----------------------
77
- user@localhost bash$ frobnicator
78
- bash: frobnicator: command not found
79
- ----------------------
80
-
81
- We verify that `/opt/local/bin` is not in `PATH`:
82
-
83
- [source,sh]
84
- ----------------------
85
- user@localhost bash$ echo $PATH
86
- /bin:/usr/bin:/usr/local/bin
87
- ----------------------
88
-
89
- We can run `frobnicator` through it's full path...
90
-
91
- [source,sh]
92
- ----------------------
93
- user@localhost bash$ /opt/local/bin/frobnicator
94
- # => success!
95
- ----------------------
96
-
97
- ...or we can add `/opt/local/bin` to `PATH`.
98
-
99
- [source,sh]
100
- ----------------------
101
- user@localhost bash$ export PATH=$PATH:/opt/local/bin
102
- user@localhost bash$ frobnicator
103
- # => success!
104
- ----------------------
10
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#the-path-environment-variable
105
11
 
106
12
  ==== Adding Phusion Passenger's administration tools to PATH
107
13
 
108
- If you get a "command not found" error when invoking one of the Phusion Passenger administration tools (e.g. `passenger-status` or `passenger-memory-stats` then that means the tools are not in `PATH`, so you need to add them.
109
-
110
- * If you <<rubygems_generic_install,installed Phusion Passenger with RubyGems>>, then the tools are in your RubyGems executable path. You can view the gem path using the command `gem env`:
111
- +
112
- ------------------------------
113
- $ gem env
114
- RubyGems Environment:
115
- - RUBYGEMS VERSION: 1.8.15
116
- - RUBY VERSION: 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin10.8.0]
117
- - INSTALLATION DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
118
- - RUBY EXECUTABLE: /opt/ruby-enterprise-1.8.7-2010.01/bin/ruby
119
- - EXECUTABLE DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/bin <--------- !!
120
- - RUBYGEMS PLATFORMS:
121
- - ruby
122
- - x86-darwin-10
123
- - GEM PATHS:
124
- - /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
125
- - /Users/hongli/.gem/ruby/1.8
126
- - GEM CONFIGURATION:
127
- - :update_sources => true
128
- - :verbose => true
129
- - :benchmark => false
130
- - :backtrace => false
131
- - :bulk_threshold => 1000
132
- - "gem" => "--no-ri --no-rdoc"
133
- - REMOTE SOURCES:
134
- - http://rubygems.org/
135
- ------------------------------
136
- +
137
- As you can see, the RubyGems executable path in the example happens to be `/opt/ruby-enterprise-1.8.7-2010.01/bin`. So that directory must be added to `PATH`.
138
-
139
- * If you <<tarball_generic_install,installed Phusion Passenger using the tarball>>, then the tools are in the `bin` subdirectory of the Phusion Passenger tarball directory that you extracted. For example, if you extracted `passenger-4.9.0.tar.gz` inside `/opt`, then the tools are located in `/opt/passenger-4.0.9/bin`. In that case, you need to add `/opt/passenger-4.0.9/bin` to your `PATH`.
140
- * If you installed Phusion Passenger using native OS packages, then some Phusion Passenger administration tools are in `/usr/bin`, while others are in `/usr/sbin`. If you are not logged in as root, then `/usr/sbin` may not be in `PATH`, which would explain why you get a "command not found" when trying to invoke some of the tools. You should `/usr/sbin` to `PATH`.
141
- * If you are unsure where your Phusion Passenger directory is then you can use the `find` command to look them up. Go to the root directory and invoke `find` with `sudo`:
142
- +
143
- --------------------------------
144
- $ cd /
145
- $ sudo find . -name passenger-status
146
- /usr/local/passenger/bin/passenger-status
147
- --------------------------------
148
- +
149
- In this example, the administration tools happen to be in `/usr/local/passenger/bin`, so you must add that to `PATH`.
150
-
151
- NOTE: You may still get a "command not found" when invoking the tools through sudo, even after you've added the relevant directory to `PATH`. Please read <<env_vars_and_sudo,Environment variables and sudo>> to learn more.
14
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#adding-passenger-s-administration-tools-to-path
152
15
 
153
16
  === Making environment variables permanent
154
17
 
155
- When you exit your shell, the evironment variable changes are lost. There is no standard method to set environment variables system-wide, so you have to set them in different configuration files for different services.
18
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#making-environment-variables-permanent
156
19
 
157
20
  ==== bash
158
21
 
159
- To make environment variables permanent for future bash sessions **for the current user**, add them to your `~/.bashrc`:
160
-
161
- [source,sh]
162
- ---------------------------------
163
- echo 'export FOO=bar' >> ~/.bashrc
164
- echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc
165
- ---------------------------------
166
-
167
- To make them permanent for future bash sessions **for all users**, add them to `/etc/bashrc`.
168
-
169
- NOTE: Depending on the system, the bashrc file may have a different filename. On Debian and Ubuntu, it's `/etc/bash.bashrc`.
170
- NOTE: Make sure your `~/.bashrc` is actually included by your `~/.profile`, which might not be the case if you created the user with `useradd` instead of `adduser` for example
22
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#bash
171
23
 
172
24
  ==== Apache
173
25
 
174
- NOTE: This subsection describes how to set environment variables on Apache itself, not on apps served through Phusion Passenger for Apache. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also <<env_vars_passenger_apps,Setting environment variables on Phusion Passenger-served apps>>.
175
-
176
- On Debian and Ubuntu, with an Apache installed through apt, Apache environment variables are defined in the file `/etc/apache2/envvars`. This is a shell script so environment variables must be specified with the shell syntax.
177
-
178
- On Red Hat, Fedora, CentOS and ScientificLinux, with an Apache installed through YUM, Apache environment variables are defined in `/etc/sysconfig/httpd`.
179
-
180
- On OS X they are defined in `/System/Library/LaunchDaemons/org.apache.httpd.plist`, as explained link:http://stackoverflow.com/questions/6833939/path-environment-variable-for-apache2-on-mac[here on Stack Overflow].
181
-
182
- On other systems, or if you did not install Apache through the system's package manager, the configuration file for environment variables is specific to the vendor that supplied Apache. There may not even be such a configuration file. You should contact the vendor for support.
26
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache
183
27
 
184
28
  ==== Nginx
185
29
 
186
- NOTE: This subsection describes how to set environment variables on Nginx itself, not on apps served through Phusion Passenger for Nginx. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also <<env_vars_passenger_apps,Setting environment variables on Phusion Passenger-served apps>>.
187
-
188
- If you installed Nginx through <<install_on_debian_ubuntu,the Debian or Ubuntu packages>>, then you can define environment variables in `/etc/default/nginx`. This is a shell script so you must use the `export FOO=bar` syntax.
189
-
190
- Otherwise, environment variables are best set through the script which starts Nginx. For example, if you installed Nginx from source and you used
191
- ifdef::apache[]
192
- the Nginx init script described in the link:Users%20guide%20Nginx.html[Phusion Passenger Users Guide, Nginx version],
193
- endif::apache[]
194
- ifdef::nginx[]
195
- <<nginx_init_script,the Nginx init script described earlier in this manual>>,
196
- endif::nginx[]
197
- then you should edit that script to define the environment variables. Those init scripts are regular shell scripts, so use the `export FOO=bar` syntax. Just make sure your set your environment variables before the script starts Nginx.
198
-
199
- NOTE: Setting environment variables on Nginx has no effect on the <<flying_passenger,Flying Passenger daemon>> because the daemon is started seperately. You should set the environment variables in the shell right before starting the daemon.
30
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#nginx
200
31
 
201
32
  ==== cron
202
33
 
203
- To make environment variables permanent for cron jobs, add those variables to the relevant crontab. But note that inside crontabs you cannot refer to existing environment variables with the `$` syntax because crontabs are not shell scripts. You have to specify the entire value.
204
-
205
- .What to put in "crontab -e"
206
- -------------------------
207
- # Environment variable definitions
208
- FOO=bar
209
- APXS2=/usr/sbin/apxs2
210
-
211
- # **WRONG!** You cannot refer to existing variables with the `$` syntax!
212
- PATH=/usr/bin:$PATH
213
- # **WRONG!** You cannot use the 'export' keyword!
214
- export PATH=/usr/bin:/usr/local/bin
215
- # Correct:
216
- PATH=/usr/bin:/usr/local/bin
217
-
218
- # Jobs:
219
- # m h dom mon dow command
220
- * * * * * frobnicator
221
- -------------------------
34
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#cron
222
35
 
223
36
  [[env_vars_passenger_apps]]
224
37
  ==== Phusion Passenger-served apps
225
38
 
226
- You can pass environment variables to Phusion Passenger-served apps through various methods:
227
-
228
- * When running Apache, use the `PassEnv` and `SetEnv` directives of link:http://httpd.apache.org/docs/2.4/mod/mod_env.html[mod_env]. This is supported starting from Phusion Passenger 4.0.
229
- * When running Nginx, use the <<PassengerEnvVar,passenger_env_var>> directive.
230
- * Through your `bashrc`. Starting from version 4.0, Phusion Passenger 4.0 spawns applications through bash and inherit all bash environment variables. Phusion Passenger Standalone tends to be started from the shell and thus inherits all environment variables set by the shell.
231
- * Through Apache and Nginx, as described earlier in this chapter. Any environment variables that you set on Apache and Nginx itself are inherited by Phusion Passenger, and thus by Phusion Passenger-served apps as well.
232
- * Through the application itself. Most programming languages provide APIs for setting environment variables. For example in Ruby you can write:
233
- +
234
- [source,ruby]
235
- -------------------
236
- ENV['FOO'] = 'bar'
237
- -------------------
238
- +
239
- In Python you can write:
240
- +
241
- [source,python]
242
- -------------------
243
- import os
244
- os.environ['FOO'] = 'bar'
245
- -------------------
39
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#passenger-served-apps
246
40
 
247
41
  [[env_vars_and_sudo]]
248
42
  === Environment variables and sudo
249
43
 
250
- NOTE: RVM users should always use the `rvmsudo` command instead of `sudo`. However all information in this section apply to `rvmsudo` as well.
251
-
252
- The `sudo` command resets all environment variables before running the specified command, for security reasons. So if you set environment variables before running `sudo passenger-install-xxx-module`, `sudo passenger-status` or any other commands, then the environment variables are not correctly passed to the command. You can solve this by running sudo with `-E` (preserve environment variables):
253
-
254
- [source,sh]
255
- -------------------------
256
- user@localhost bash$ export APXS2=/usr/sbin/apxs2
257
- user@localhost bash$ sudo -E passenger-install-apache2-module
258
- -------------------------
259
-
260
- Alternatively, you can obtain a root prompt with sudo first, and *then* set the environment variables, before running any further commands:
261
-
262
- -------------------------
263
- user@localhost bash$ sudo -s
264
- Password: ...
265
- root@localhost bash# export APXS2=/usr/sbin/apxs2
266
- root@localhost bash# passenger-install-apache2-module
267
- -------------------------
268
-
269
- Note that for security reasons, `sudo` **always resets the `PATH` environment variable**, even if you pass `-E`! You can get around this problem by obtaining a root prompt first, and then set the environment variables:
270
-
271
- -------------------------
272
- user@localhost bash$ sudo -s
273
- Password: ...
274
- root@localhost bash# export PATH=$PATH:/opt/myruby/bin
275
- root@localhost bash# passenger-install-apache2-module
276
- -------------------------
44
+ This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#environment-variables-and-sudo