/[gentoo]/xml/htdocs/doc/en/handbook/hb-working-rcscripts.xml
Gentoo

Contents of /xml/htdocs/doc/en/handbook/hb-working-rcscripts.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.26 - (hide annotations) (download) (as text)
Thu Sep 7 08:23:02 2006 UTC (8 years ago) by nightmorph
Branch: MAIN
Changes since 1.25: +76 -11 lines
File MIME type: application/xml
updated stop-start-daemon documentation for bug 122786

1 swift 1.10 <?xml version='1.0' encoding='UTF-8'?>
2     <!DOCTYPE sections SYSTEM "/dtd/book.dtd">
3    
4 swift 1.1 <!-- The content of this document is licensed under the CC-BY-SA license -->
5 neysx 1.25 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
6 swift 1.1
7 nightmorph 1.26 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-rcscripts.xml,v 1.25 2006/03/14 19:29:29 neysx Exp $ -->
8 swift 1.1
9     <sections>
10 swift 1.18
11 nightmorph 1.26 <version>1.22</version>
12     <date>2006-09-07</date>
13 swift 1.18
14 swift 1.1 <section>
15     <title>Runlevels</title>
16     <subsection>
17 swift 1.4 <title>Booting your System</title>
18     <body>
19    
20     <p>
21     When you boot your system, you will notice lots of text floating by. If you pay
22     close attention, you will notice this text is the same every time you reboot
23     your system. The sequence of all these actions is called the <e>boot
24     sequence</e> and is (more or less) statically defined.
25     </p>
26    
27     <p>
28     First, your boot loader will load the kernel image you have defined in the
29     boot loader configuration into memory after which it tells the CPU to run the
30 swift 1.6 kernel. When the kernel is loaded and run, it initializes all kernel-specific
31 swift 1.4 structures and tasks and starts the <c>init</c> process.
32     </p>
33    
34     <p>
35     This process then makes sure that all filesystems (defined in
36     <path>/etc/fstab</path>) are mounted and ready to be used. Then it executes
37     several scripts located in <path>/etc/init.d</path>, which will start the
38 swift 1.8 services you need in order to have a successfully booted system.
39 swift 1.4 </p>
40    
41     <p>
42     Finally, when all scripts are executed, <c>init</c> activates the terminals
43 swift 1.14 (in most cases just the virtual consoles which are hidden beneath <c>Alt-F1</c>,
44 swift 1.4 <c>Alt-F2</c>, etc.) attaching a special process called <c>agetty</c> to it.
45     This process will then make sure you are able to log on through these terminals
46     by running <c>login</c>.
47     </p>
48    
49     </body>
50     </subsection>
51     <subsection>
52     <title>Init Scripts</title>
53 swift 1.1 <body>
54    
55 swift 1.2 <p>
56 swift 1.4 Now <c>init</c> doesn't just execute the scripts in <path>/etc/init.d</path>
57     randomly. Even more, it doesn't run all scripts in <path>/etc/init.d</path>,
58 swift 1.7 only the scripts it is told to execute. It decides which scripts to execute by
59 swift 1.4 looking into <path>/etc/runlevels</path>.
60     </p>
61    
62     <p>
63     First, <c>init</c> runs all scripts from <path>/etc/init.d</path> that have
64     symbolic links inside <path>/etc/runlevels/boot</path>. Usually, it will
65     start the scripts in alphabetical order, but some scripts have dependency
66     information in them, telling the system that another script must be run before
67     they can be started.
68     </p>
69    
70     <p>
71     When all <path>/etc/runlevels/boot</path> referenced scripts are executed,
72     <c>init</c> continues with running the scripts that have a symbolic link to them
73     in <path>/etc/runlevels/default</path>. Again, it will use the alphabetical
74     order to decide what script to run first, unless a script has dependency
75 swift 1.7 information in it, in which case the order is changed to provide a valid
76     start-up sequence.
77 swift 1.2 </p>
78    
79     </body>
80     </subsection>
81     <subsection>
82 swift 1.4 <title>How Init Works</title>
83 swift 1.2 <body>
84    
85     <p>
86 swift 1.4 Of course <c>init</c> doesn't decide all that by itself. It needs a
87     configuration file that specifies what actions need to be taken. This
88     configuration file is <path>/etc/inittab</path>.
89 swift 1.2 </p>
90    
91 swift 1.4 <p>
92 neysx 1.16 If you remember the boot sequence we have just described, you will remember
93     that <c>init</c>'s first action is to mount all filesystems. This is defined in
94     the following line from <path>/etc/inittab</path>:
95 swift 1.4 </p>
96    
97     <pre caption="The system initialisation line in /etc/inittab">
98 swift 1.2 si::sysinit:/sbin/rc sysinit
99     </pre>
100    
101     <p>
102 swift 1.4 This line tells <c>init</c> that it must run <c>/sbin/rc sysinit</c> to
103 swift 1.6 initialize the system. The <path>/sbin/rc</path> script takes care of the
104 swift 1.4 initialisation, so you might say that <c>init</c> doesn't do much -- it
105     delegates the task of initialising the system to another process.
106 swift 1.2 </p>
107    
108     <p>
109 swift 1.4 Second, <c>init</c> executed all scripts that had symbolic links in
110     <path>/etc/runlevels/boot</path>. This is defined in the following line:
111 swift 1.2 </p>
112    
113 swift 1.4 <pre caption="The system initialisation, continued">
114     rc::bootwait:/sbin/rc boot
115 swift 1.2 </pre>
116    
117     <p>
118 swift 1.4 Again the <c>rc</c> script performs the necessary tasks. Note that the option
119     given to <c>rc</c> (<e>boot</e>) is the same as the subdirectory of
120     <path>/etc/runlevels</path> that is used.
121 swift 1.2 </p>
122    
123     <p>
124 swift 1.4 Now <c>init</c> checks its configuration file to see what <e>runlevel</e> it
125     should run. To decide this, it reads the following line from
126     <path>/etc/inittab</path>:
127 swift 1.2 </p>
128    
129 swift 1.4 <pre caption="The initdefault line">
130     id:3:initdefault:
131     </pre>
132 swift 1.2
133     <p>
134 swift 1.4 In this case (which the majority of Gentoo users will use), the <e>runlevel</e>
135     id is 3. Using this information, <c>init</c> checks what it must run to start
136     <e>runlevel 3</e>:
137 swift 1.2 </p>
138    
139 swift 1.4 <pre caption="The runlevel definitions">
140 swift 1.2 l0:0:wait:/sbin/rc shutdown
141     l1:S1:wait:/sbin/rc single
142     l2:2:wait:/sbin/rc nonetwork
143     l3:3:wait:/sbin/rc default
144     l4:4:wait:/sbin/rc default
145     l5:5:wait:/sbin/rc default
146     l6:6:wait:/sbin/rc reboot
147     </pre>
148    
149     <p>
150 swift 1.4 The line that defines level 3, again, uses the <c>rc</c> script to start the
151     services (now with argument <e>default</e>). Again note that the argument of
152     <c>rc</c> is the same as the subdirectory from <path>/etc/runlevels</path>.
153 swift 1.2 </p>
154    
155     <p>
156 swift 1.4 When <c>rc</c> has finished, <c>init</c> decides what virtual consoles it should
157     activate and what commands need to be run at each console:
158 swift 1.2 </p>
159    
160 swift 1.4 <pre caption="The virtual consoles definition">
161     c1:12345:respawn:/sbin/agetty 38400 tty1 linux
162     c2:12345:respawn:/sbin/agetty 38400 tty2 linux
163     c3:12345:respawn:/sbin/agetty 38400 tty3 linux
164     c4:12345:respawn:/sbin/agetty 38400 tty4 linux
165     c5:12345:respawn:/sbin/agetty 38400 tty5 linux
166     c6:12345:respawn:/sbin/agetty 38400 tty6 linux
167     </pre>
168    
169 swift 1.1
170     </body>
171     </subsection>
172     <subsection>
173 swift 1.4 <title>What is a runlevel?</title>
174 swift 1.1 <body>
175    
176 swift 1.2 <p>
177 swift 1.4 You have seen that <c>init</c> uses a numbering scheme to decide what
178     <e>runlevel</e> it should activate. A <e>runlevel</e> is a state in which
179     your system is running and contains a collection of scripts (runlevel scripts or
180     <e>initscripts</e>) that must be executed when you enter or leave a runlevel.
181     </p>
182    
183     <p>
184     In Gentoo, there are seven runlevels defined: three internal runlevels, and four
185     user-defined runlevels. The internal runlevels are called <e>sysinit</e>,
186     <e>shutdown</e> and <e>reboot</e> and do exactly what their names imply:
187 swift 1.6 initialize the system, powering off the system and rebooting the system.
188 swift 1.4 </p>
189    
190     <p>
191     The user-defined runlevels are those with an accompanying
192     <path>/etc/runlevels</path> subdirectory: <path>boot</path>,
193     <path>default</path>, <path>nonetwork</path> and <path>single</path>. The
194     <path>boot</path> runlevel starts all system-necessary services which all other
195     runlevels use. The remaining three runlevels differ in what services they start:
196     <path>default</path> is used for day-to-day operations, <path>nonetwork</path>
197     is used in case no network connectivity is required, and <path>single</path> is
198     used when you need to fix the system.
199 swift 1.2 </p>
200    
201 swift 1.4 </body>
202     </subsection>
203     <subsection>
204     <title>Working with the Init Scripts</title>
205     <body>
206    
207 swift 1.2 <p>
208 swift 1.4 The scripts that the <c>rc</c> process starts are called <e>init scripts</e>.
209 swift 1.2 Each script in <path>/etc/init.d</path> can be executed with the arguments
210     <e>start</e>, <e>stop</e>, <e>restart</e>, <e>pause</e>, <e>zap</e>,
211     <e>status</e>, <e>ineed</e>, <e>iuse</e>, <e>needsme</e>, <e>usesme</e> or
212     <e>broken</e>.
213     </p>
214    
215     <p>
216     To start, stop or restart a service (and all depending services), <c>start</c>,
217     <c>stop</c> and <c>restart</c> should be used:
218     </p>
219    
220     <pre caption="Starting Postfix">
221     # <i>/etc/init.d/postfix start</i>
222     </pre>
223 swift 1.4
224     <note>
225     Only the services that <e>need</e> the given service are stopped or restarted.
226     The other depending services (those that <e>use</e> the service but don't need
227     it) are left untouched.
228     </note>
229 swift 1.2
230     <p>
231     If you want to stop a service, but not the services that depend on it, you can
232     use the <c>pause</c> argument:
233     </p>
234    
235     <pre caption="Stopping Postfix but keep the depending services running">
236     # <i>/etc/init.d/postfix pause</i>
237     </pre>
238    
239     <p>
240     If you want to see what status a service has (started, stopped, paused, ...) you
241     can use the <c>status</c> argument:
242     </p>
243    
244     <pre caption="Status information for postfix">
245     # <i>/etc/init.d/postfix status</i>
246     </pre>
247    
248     <p>
249 swift 1.3 If the status information tells you that the service is running, but you know
250     that it is not, then you can reset the status information to "stopped" with the
251     <c>zap</c> argument:
252 swift 1.2 </p>
253    
254     <pre caption="Resetting status information for postfix">
255     # <i>/etc/init.d/postfix zap</i>
256     </pre>
257    
258     <p>
259     To also ask what dependencies the service has, you can use <c>iuse</c> or
260     <c>ineed</c>. With <c>ineed</c> you can see the services that are really
261     necessary for the correct functioning of the service. <c>iuse</c> on the other
262     hand shows the services that can be used by the service, but are not necessary
263     for the correct functioning.
264     </p>
265    
266     <pre caption="Requesting a list of all necessary services on which Postfix depends">
267     # <i>/etc/init.d/postfix ineed</i>
268     </pre>
269    
270     <p>
271     Similarly, you can ask what services require the service (<c>needsme</c>) or can
272     use it (<c>usesme</c>):
273     </p>
274    
275     <pre caption="Requesting a list of all services that require Postfix">
276     # <i>/etc/init.d/postfix needsme</i>
277     </pre>
278    
279     <p>
280 neysx 1.16 Finally, you can ask what dependencies the service requires that are missing:
281 swift 1.2 </p>
282    
283     <pre caption="Requesting a list of missing dependencies for Postfix">
284     # <i>/etc/init.d/postfix broken</i>
285     </pre>
286 swift 1.1
287     </body>
288     </subsection>
289     </section>
290     <section>
291     <title>Working with rc-update</title>
292     <subsection>
293     <title>What is rc-update?</title>
294     <body>
295    
296 swift 1.2 <p>
297     Gentoo's init system uses a dependency-tree to decide what service needs to be
298 neysx 1.16 started first. As this is a tedious task that we wouldn't want our users to
299     have to do manually, we have created tools that ease the administration of the
300     runlevels and init scripts.
301 swift 1.2 </p>
302    
303     <p>
304     With <c>rc-update</c> you can add and remove init scripts to a runlevel. The
305     <c>rc-update</c> tool will then automatically ask the <c>depscan.sh</c> script
306     to rebuild the dependency tree.
307     </p>
308    
309 swift 1.1 </body>
310     </subsection>
311     <subsection>
312     <title>Adding and Removing Services</title>
313     <body>
314    
315 swift 1.2 <p>
316     You have already added init scripts to the "default" runlevel during the
317 swift 1.7 installation of Gentoo. At that time you might not have had a clue what the
318 swift 1.2 "default" is for, but now you should. The <c>rc-update</c> script requires a
319     second argument that defines the action: <e>add</e>, <e>del</e> or <e>show</e>.
320     </p>
321    
322     <p>
323     To add or remove an init script, just give <c>rc-update</c> the <c>add</c> or
324     <c>del</c> argument, followed by the init script and the runlevel. For instance:
325     </p>
326    
327     <pre caption="Removing Postfix from the default runlevel">
328     # <i>rc-update del postfix default</i>
329     </pre>
330    
331     <p>
332     The <c>rc-update show</c> command will show all the available init scripts and
333     list at which runlevels they will execute:
334     </p>
335    
336     <pre caption="Receiving init script information">
337     # <i>rc-update show</i>
338     </pre>
339 swift 1.1
340     </body>
341     </subsection>
342     </section>
343     <section>
344     <title>Configuring Services</title>
345     <subsection>
346 swift 1.2 <title>Why the Need for Extra Configuration?</title>
347 swift 1.1 <body>
348    
349 swift 1.2 <p>
350 neysx 1.16 Init scripts can be quite complex. It is therefore not really desirable to
351     have the users edit the init script directly, as it would make it more
352 swift 1.5 error-prone. It is however important to be able to configure such a service. For
353     instance, you might want to give more options to the service itself.
354 swift 1.2 </p>
355    
356     <p>
357 neysx 1.16 A second reason to have this configuration outside the init script is to be
358     able to update the init scripts without the fear that your configuration
359     changes will be undone.
360 swift 1.2 </p>
361    
362 swift 1.1 </body>
363     </subsection>
364     <subsection>
365     <title>The /etc/conf.d Directory</title>
366     <body>
367    
368 swift 1.2 <p>
369     Gentoo provides an easy way to configure such a service: every init script that
370     can be configured has a file in <path>/etc/conf.d</path>. For instance, the
371     apache2 initscript (called <path>/etc/init.d/apache2</path>) has a
372     configuration file called <path>/etc/conf.d/apache2</path>, which can contain
373     the options you want to give to the Apache 2 server when it is started:
374     </p>
375    
376     <pre caption="Variable defined in /etc/conf.d/apache2">
377     APACHE2_OPTS="-D PHP4"
378     </pre>
379    
380     <p>
381     Such a configuration file contains variables and variables alone (just like
382     <path>/etc/make.conf</path>), making it very easy to configure services. It also
383     allows us to provide more information about the variables (as comments).
384     </p>
385    
386 swift 1.1 </body>
387     </subsection>
388     </section>
389     <section>
390 swift 1.2 <title>Writing Init Scripts</title>
391 swift 1.1 <subsection>
392     <title>Do I Have To?</title>
393     <body>
394    
395 swift 1.2 <p>
396 neysx 1.16 No, writing an init script is usually not necessary as Gentoo provides
397 swift 1.2 ready-to-use init scripts for all provided services. However, you might have
398     installed a service without using Portage, in which case you will most likely
399     have to create an init script.
400     </p>
401    
402     <p>
403     Do not use the init script provided by the service if it isn't explicitly
404     written for Gentoo: Gentoo's init scripts are not compatible with the init
405     scripts used by other distributions!
406     </p>
407    
408 swift 1.1 </body>
409     </subsection>
410     <subsection>
411     <title>Layout</title>
412     <body>
413    
414 swift 1.2 <p>
415     The basic layout of an init script is shown below.
416     </p>
417    
418     <pre caption="Basic layout of an init script">
419     #!/sbin/runscript
420    
421     depend() {
422     <comment>(Dependency information)</comment>
423     }
424    
425     start() {
426     <comment>(Commands necessary to start the service)</comment>
427     }
428    
429     stop() {
430     <comment>(Commands necessary to stop the service)</comment>
431     }
432    
433     restart() {
434     <comment>(Commands necessary to restart the service)</comment>
435     }
436     </pre>
437    
438     <p>
439     Any init script <e>requires</e> the <c>start()</c> function to be defined. All
440     other sections are optional.
441     </p>
442    
443 swift 1.1 </body>
444     </subsection>
445     <subsection>
446     <title>Dependencies</title>
447     <body>
448    
449 swift 1.2 <p>
450     There are two dependencies you can define: <c>use</c> and <c>need</c>. As we
451     have mentioned before, the <c>need</c> dependency is more strict than the
452     <c>use</c> dependency. Following this dependency type you enter the service
453     you depend on, or the <e>virtual</e> dependency.
454     </p>
455    
456     <p>
457     A <e>virtual</e> dependency is a dependency that a service provides, but that is
458     not provided solely by that service. Your init script can depend on a system
459     logger, but there are many system loggers available (metalogd, syslog-ng,
460     sysklogd, ...). As you cannot <c>need</c> every single one of them (no sensible
461     system has all these system loggers installed and running) we made sure that
462     all these services <c>provide</c> a virtual dependency.
463     </p>
464    
465     <p>
466     Let us take a look at the dependency information for the postfix service.
467     </p>
468    
469     <pre caption="Dependency information for Postfix">
470     depend() {
471     need net
472     use logger dns
473     provide mta
474     }
475     </pre>
476    
477     <p>
478     As you can see, the postfix service:
479     </p>
480    
481     <ul>
482     <li>
483     requires the (virtual) <c>net</c> dependency (which is provided by, for
484     instance, <path>/etc/init.d/net.eth0</path>)
485     </li>
486     <li>
487     uses the (virtual) <c>logger</c> dependency (which is provided by, for
488     instance, <path>/etc/init.d/syslog-ng</path>)
489     </li>
490     <li>
491     uses the (virtual) <c>dns</c> dependency (which is provided by, for
492     instance, <path>/etc/init.d/named</path>)
493     </li>
494     <li>
495     provides the (virtual) <c>mta</c> dependency (which is common for all mail
496     servers)
497     </li>
498     </ul>
499    
500 swift 1.1 </body>
501     </subsection>
502     <subsection>
503     <title>Controlling the Order</title>
504     <body>
505    
506 swift 1.2 <p>
507     In some cases you might not require a service, but want your service to be
508     started <c>before</c> (or <c>after</c>) another service <e>if</e> it is
509     available on the system (note the conditional - this is no dependency anymore)
510 swift 1.17 <e>and</e> run in the same runlevel (note the conditional - only services in the
511 swift 1.2 same runlevel are involved). You can provide this information using the
512     <c>before</c> or <c>after</c> settings.
513     </p>
514    
515     <p>
516     As an example we view the settings of the Portmap service:
517     </p>
518    
519     <pre caption="The depend() function in the Portmap service">
520     depend() {
521     need net
522     before inetd
523     before xinetd
524     }
525     </pre>
526    
527     <p>
528     You can also use the "*" glob to catch all services in the same runlevel,
529 neysx 1.16 although this isn't advisable.
530 swift 1.2 </p>
531    
532     <pre caption="Running an init script as first script in the runlevel">
533     depend() {
534     before *
535     }
536     </pre>
537 swift 1.1
538 nightmorph 1.26 <p>
539     If your service must write to local disks, it should need <c>localmount</c>. If
540     it places anything in <path>/var/run</path> such as a pidfile, then should
541     start after <c>bootmisc</c>:
542     </p>
543    
544     <pre caption="Example depend() function">
545     depend() {
546     need localmount
547     after bootmisc
548     }
549     </pre>
550    
551 swift 1.1 </body>
552     </subsection>
553     <subsection>
554     <title>Standard Functions</title>
555     <body>
556    
557 swift 1.2 <p>
558     Next to the <c>depend()</c> functionality, you also need to define the
559     <c>start()</c> function. This one contains all the commands necessary to
560 neysx 1.16 initialize your service. It is advisable to use the <c>ebegin</c> and
561 swift 1.2 <c>eend</c> functions to inform the user about what is happening:
562     </p>
563    
564     <pre caption="Example start() function">
565     start() {
566     ebegin "Starting my_service"
567 nightmorph 1.26 start-stop-daemon --start --exec /path/to/my_service \
568     --pidfile /path/to/my_pidfile
569 swift 1.2 eend $?
570     }
571     </pre>
572    
573     <p>
574 nightmorph 1.26 Both <c>--exec</c> and <c>--pidfile</c> should be used in start and stop
575     functions. If the service does not create a pidfile, then use
576     <c>--make-pidfile</c> if possible, though you should test this to be sure.
577     Otherwise, don't use pidfiles. You can also add <c>--quiet</c> to the
578     <c>start-stop-daemon</c> options, but this is not recommended unless the
579     service is extremely verbose. Using <c>--quiet</c> may hinder debugging if the
580     service fails to start.
581 swift 1.2 </p>
582    
583 nightmorph 1.26 <note>
584     Make sure that <c>--exec</c> actually calls a service and not just a shell
585     script that launches services and exits -- that's what the init script is
586     supposed to do.
587     </note>
588    
589     <p>
590     If you need more examples of the <c>start()</c> function, please read the
591     source code of the available init scripts in your <path>/etc/init.d</path>
592     directory.
593     </p>
594 swift 1.2
595     <p>
596     Other functions you can define are: <c>stop()</c> and <c>restart()</c>. You are
597     not obliged to define these functions! Our init system is intelligent enough to
598 swift 1.9 fill these functions by itself if you use <c>start-stop-daemon</c>.
599 swift 1.2 </p>
600    
601 swift 1.21 <p>
602 nightmorph 1.26 Although you do not <e>have</e> to create a <c>stop()</c> function, here is an
603     example:
604     </p>
605    
606     <pre caption="Example stop() function">
607     stop() {
608     ebegin "Stopping my_service"
609     start-stop-daemon --stop --exec /path/to/my_service \
610     --pidfile /path/to/my_pidfile
611     eend $?
612     }
613     </pre>
614    
615     <p>
616     If your service runs some other script (for example, bash, python, or perl),
617     and this script later changes names (for example, <c>foo.py</c> to <c>foo</c>),
618     then you will need to add <c>--name</c> to <c>start-stop-daemon</c>. You must
619     specify the name that your script will be changed to. In this example, a
620     service starts <c>foo.py</c>, which changes names to <c>foo</c>:
621     </p>
622    
623     <pre caption="A service that starts the foo script">
624     start() {
625     ebegin "Starting my_script"
626     start-stop-daemon --start --exec /path/to/my_script \
627     --pidfile /path/to/my_pidfile --name foo
628     eend $?
629     }
630     </pre>
631    
632     <p>
633     <c>start-stop-daemon</c> has an excellent man page available if you need more
634     information:
635     </p>
636    
637     <pre caption="Getting the man page for start-stop-daemon">
638     $ <i>man start-stop-daemon</i>
639     </pre>
640    
641     <p>
642 swift 1.21 Gentoo's init script syntax is based on the Bourne Again Shell (bash) so you are
643     free to use bash-compatible constructs inside your init script.
644     </p>
645    
646 swift 1.1 </body>
647     </subsection>
648     <subsection>
649     <title>Adding Custom Options</title>
650     <body>
651    
652 swift 1.2 <p>
653     If you want your init script to support more options than the ones we have
654     already encountered, you should add the option to the <c>opts</c> variable, and
655     create a function with the same name as the option. For instance, to support an
656     option called <c>restartdelay</c>:
657     </p>
658    
659     <pre caption="Supporting the restartdelay option">
660     opts="${opts} restartdelay"
661    
662     restartdelay() {
663 swift 1.24 stop
664 swift 1.2 sleep 3 <comment># Wait 3 seconds before starting again</comment>
665 swift 1.24 start
666 swift 1.2 }
667     </pre>
668    
669 swift 1.1 </body>
670     </subsection>
671     <subsection>
672     <title>Service Configuration Variables</title>
673     <body>
674 swift 1.2
675     <p>
676     You don't have to do anything to support a configuration file in
677     <path>/etc/conf.d</path>: if your init script is executed, the following files
678     are automatically sourced (i.e. the variables are available to use):
679     </p>
680    
681     <ul>
682     <li><path>/etc/conf.d/&lt;your init script&gt;</path></li>
683     <li><path>/etc/conf.d/basic</path></li>
684     <li><path>/etc/rc.conf</path></li>
685     </ul>
686    
687     <p>
688     Also, if your init script provides a virtual dependency (such as <c>net</c>),
689     the file associated with that dependency (such as <path>/etc/conf.d/net</path>)
690     will be sourced too.
691     </p>
692 swift 1.1
693     </body>
694     </subsection>
695     </section>
696 swift 1.12 <section>
697     <title>Changing the Runlevel Behaviour</title>
698     <subsection>
699     <title>Who might benefit from this?</title>
700     <body>
701    
702     <p>
703     Many laptop users know the situation: at home you need to start <c>net.eth0</c>
704     while you don't want to start <c>net.eth0</c> while you're on the road (as
705     there is no network available). With Gentoo you can alter the runlevel behaviour
706     to your own will.
707     </p>
708    
709     <p>
710     For instance you can create a second "default" runlevel which you can boot that
711     has other init scripts assigned to it. You can then select at boottime what
712 dertobi123 1.15 default runlevel you want to use.
713 swift 1.12 </p>
714    
715     </body>
716     </subsection>
717     <subsection>
718 neysx 1.22 <title>Using softlevel</title>
719 swift 1.12 <body>
720    
721     <p>
722     First of all, create the runlevel directory for your second "default" runlevel.
723     As an example we create the <path>offline</path> runlevel:
724     </p>
725    
726     <pre caption="Creating a runlevel directory">
727     # <i>mkdir /etc/runlevels/offline</i>
728     </pre>
729    
730     <p>
731     Add the necessary init scripts to the newly created runlevels. For instance, if
732     you want to have an exact copy of your current <c>default</c> runlevel but
733     without <c>net.eth0</c>:
734     </p>
735    
736     <pre caption="Adding the necessary init scripts">
737 neysx 1.22 <comment>(Copy all services from default runlevel to offline runlevel)</comment>
738 neysx 1.23 # <i>cd /etc/runlevels/default</i>
739     # <i>for service in *; do rc-update add $service offline; done</i>
740 neysx 1.22 <comment>(Remove unwanted service from offline runlevel)</comment>
741     # <i>rc-update del net.eth0 offline</i>
742     <comment>(Display active services for offline runlevel)</comment>
743     # <i>rc-update show offline</i>
744     <comment>(Partial sample Output)</comment>
745     acpid | offline
746     domainname | offline
747     local | offline
748     net.eth0 |
749 swift 1.12 </pre>
750    
751     <p>
752     Now edit your bootloader configuration and add a new entry for the
753     <c>offline</c> runlevel. For instance, in <path>/boot/grub/grub.conf</path>:
754     </p>
755    
756     <pre caption="Adding an entry for the offline runlevel">
757     title Gentoo Linux Offline Usage
758     root (hd0,0)
759     kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 <i>softlevel=offline</i>
760     </pre>
761    
762     <p>
763 neysx 1.22 VoilĂ , you're all set now. If you boot your system and select the newly added
764 swift 1.12 entry at boot, the <c>offline</c> runlevel will be used instead of the
765     <c>default</c> one.
766     </p>
767    
768     </body>
769     </subsection>
770     <subsection>
771 neysx 1.22 <title>Using bootlevel</title>
772 swift 1.12 <body>
773    
774     <p>
775     Using <c>bootlevel</c> is completely analogous to <c>softlevel</c>. The only
776     difference here is that you define a second "boot" runlevel instead of a second
777     "default" runlevel.
778     </p>
779    
780     </body>
781     </subsection>
782     </section>
783 swift 1.1 </sections>

  ViewVC Help
Powered by ViewVC 1.1.20